appdotnet / api-spec

App.net API Documentation is on the web at https://developers.app.net. Source for these docs is in the new-docs branch here. Please use the issue tracker and submit pull requests! Help us build the real-time social service where users and developers come first, not advertisers.
https://developers.app.net
950 stars 98 forks source link

Channels/topics? #120

Closed ChristianRygg closed 11 years ago

ChristianRygg commented 12 years ago

(Let me just say that I haven't got a full overview of what has been said in here before, but I don't think this topic has been discussed. If I'm wrong - my bad :))

There is one concept in the social media world I have been missing: The concept of having channels/topics. Let me explain:

Let's say I'm on vacation and I take a great photo of some sight. I'd like to share that, but not with everyone, so I post it to my "Private" channel. When I get back, I find a great new Javascript framework I'd like to share with me co-geeks, but my mom won't care - so I post it on my "Geek" channel. Finally I find a recipe for goats cheese ice cream (it exists and is very tasty ;)) which I share on my "Cooking" channel.

So, how is this different from the was Facebook does things? I could just create a group and put all my Cooking-buddies in that group and share my recipe with just that group. Well, there are a few key differences and added possibilities:

1) I have to decide who wants to see my cooking posts. Perhaps my aunt is more of a cook than I know. Shouldn't she be the one to decide if she wants to see my cooking posts or not?

2) A channel could be public. By that, I mean that if you go to my profile, all my posts to public channels would be visible - even if you subscribe to them or not. You can decide if my past cooking posts were interesting enough to subscribe to my channel or not. Only if you become a subscriber, will my posts to that channel show up in your feed, though.

3) Channels could be made to be cascading, so that I can have "BBQ", "Pastry" and "Dessert" channels under my "Cooking" channel. Subscribing to my "Cooking" channel will yield all posts to channels residing in channels beneath this. One should also be able to subscribe to the top node - yielding all my post - should one so which. New channels will automatically be shown in your feed in that case.

4) Once could imagine "editor type" channels, meaning that they group others similar channels to help discovery of interesting peoples channels. Perhaps my "Geek" channel has the editor flag set. When you subscribe to it, you have the option of including my editor posts, meaning that you will also get all posts if channels I've said are relating to "Geek" in your feed.

5) For my "Private" channel I would want to be able to define what group of people I want to be able to see that channel. That doesn't mean they will see posts to that channel in their feed - but they will have the option to subscribe. Other users won't be able know the channel exists.

Personally I feel this would give control in the chaos which is social media feeds. Would this be an idea for App.Net?

jdscolam commented 12 years ago

I like this idea, though it may need some fleshing out.

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Christian Rygg notifications@github.com wrote:

(Let me just say that I haven't got a full overview of what has been said in here before, but I don't think this topic has been discussed. If I'm wrong - my bad :))

There is one concept in the social media world I have been missing: The concept of having channels/topics. Let me explain:

Let's say I'm on vacation and I take a great photo of some sight. I'd like to share that, but not with everyone, so I post it to my "Private" channel. When I get back, I find a great new Javascript framework I'd like to share with me co-geeks, but my mom won't care - so I post it on my "Geek" channel. Finally I find a recipe for goats cheese ice cream (it exists and is very tasty ;)) which I share on my "Cooking" channel.

So, how is this different from the was Facebook does things? I could just create a group and put all my Cooking-buddies in that group and share my recipe with just that group. Well, there are a few key differences and added possibilities:

1) I have to decide who wants to see my cooking posts. Perhaps my aunt is more of a cook than I know. Shouldn't she be the one to decide if she wants to see my cooking posts or not?

2) A channel could be public. By that, I mean that if you go to my profile, all my posts to public channels would be visible - even if you subscribe to them or not. You can decide if my past cooking posts were interesting enough to subscribe to my channel or not. Only if you become a subscriber, will my posts to that channel show up in your feed, though.

3) Channels could be made to be cascading, so that I can have "BBQ", "Pastry" and "Dessert" channels under my "Cooking" channel. Subscribing to my "Cooking" channel will yield all posts to channels residing in channels beneath this. One should also be able to subscribe to the top node - yielding all my post - should one so which. New channels will automatically be shown in your feed in that case.

4) Once could imagine "editor type" channels, meaning that they group others similar channels to help discovery of interesting peoples channels. Perhaps my "Geek" channel has the editor flag set. When you subscribe to it, you have the option of including my editor posts, meaning that you will also get all posts if channels I've said are relating to "Geek" in your feed.

5) For my "Private" channel I would want to be able to define what group of people I want to be able to see that channel. That doesn't mean they will see posts to that channel in their feed - but they will have the option to subscribe. Other users won't be able know the channel exists.

Personally I feel this would give control in the chaos which is social media feeds. Would this be an idea for App.Net?

— Reply to this email directly or view it on GitHub.

JoshBlake commented 12 years ago

@ChristianRygg What you are describing sounds a lot like Google+ Circles.

I don't think that type of construct belongs in the app.net core. That said, an app.net client could implement that or any number of variations of social patterns if some of the things discussed in #33 were implemented.

dquick-freelance commented 12 years ago

@JoshBlake I'm not so sure about it not belonging in the core, and I think that it actually integrates with #33 pretty directly. Let's see if I can explain my thinking on one cuppa.

Currently in the API spec, a User object has user.type which can be one of four values: 'human', 'bot', 'corporate', or 'feed'.

I'm not sure @berg et. al. have the role of each of those explicitly defined internally yet (outside of 'human') but if there was an endpoint where a user could create a new User object of type 'feed' and own it, you have a fast-track to a channel/topic in my mind. user[type='feed'].followers becomes a list of data sources that the 'feed'/channel/topic aggregates. user[type='feed'].followed_by are subscribers to the 'feed'/channel/topic.

33 comes into play to limit access to the feed, yes? Private group channels, one-on-one channels, etc.

First user referenced in a feed's followers table is owner of the feed. There could be an endpoint available to have that person re-assign ownership to another, but there would only ever be one owner (owner has to be user[type='human'] in my mind).

Am I missing something semantically that makes this onerous?

JoshBlake commented 12 years ago

@dquick-freelance I see what you mean, but I believe the user object is strongly tied to the concept of a paying account. This might change if/when they allow developers to create test accounts, or allow one account to have one or more "alt" handles. One aspect of it is that the process of reserving a user handle is strongly associated linked to the account creation process. It might be possible to circumvent that by letting one create, e.g. @joshblake:devfeed and @joshblake:private feeds, like a personal namespace for sub-user objects. Even then, though, I don't know whether the user object would make the most sense for that vs a new object based upon filtering your main stream.

ChristianRygg commented 12 years ago

@JoshBlake The all important difference between this and Googles circles is that you put a user in your Google circles and you get all of the users posts in your feed. I would just like to subscribe (for instance) to a certain software gurus posts about software development and not get the post about him being stuck, having lost the last train home - something his family might want in their feed :-) But I agree - it's similar.

stereoket commented 12 years ago

I have added a comment to #123 that talks a little bit about group settings.

markwilcox commented 12 years ago

I agree with this concept - not everyone will do it but I think people that create cleaner signals by organising their own posts in this way will get more followers for those focussed sub-streams.

I believe everything discussed here can be implemented by clients if the core supports #90 and #33.

Consider that (under the hood - no need to represent it this way in the UI) you create separate groups of users for your (public) posts on different topics which have "write self" permissions set to "all" (that is anyone can add or remove themselves from each group). To prevent every client from having to implement this scheme you can have an "all public posts" group. When your client posts something you've indicated is about cooking, access is granted to your "cooking" group and your "all public posts" group. Someone who wants to follow everything you say joins your "all public posts" group - just like the asymmetric total follow model we have now (borrowed from Twitter) but someone who only wants to see your posts about cooking only joins the "cooking" group.

From your examples, your "cooking" group could simply be defined as the intersection of your "BBQ", "Pastry" and "Dessert" groups - someone who adds themselves to "cooking" is actually added to all three sub-groups. Alternatively you could have a generic cooking group where you post cooking related things that don't fit in one of the other groups and also, when you post something about BBQ, you give access to both the "BBQ" group and the "cooking" group.

Editor channels is very much what @teawithcarl on ADN keeps talking about - I think they're a good idea. The underlying implementation here is that you create a group of users that you follow for a specific topic (or a group of public groups that they post subsets of their content to as above). Other users can then "follow" your group of users, or make their own group derived from it (maybe they union or intersect your list with someone else's, or add or remove a few people).

Note there are two levels of filtering here, one is groups created by users to split up content types, and the other is groups of users you want to see content from. With that distinction I think the concept of following someone might become unnecessary for many (particularly power users) - you add yourself to groups that get posted content you are interested in (like subscribing to a mailing list or TV channel) and then request subsets of all the content you're subscribed to for viewing as single streams. Granting yourself access to a public group/channel doesn't mean you want to look at the content all the time. Similarly with a private group/channel, the fact that the owner has given you access doesn't mean you have to view the content.

The thing missing from this picture is a decent discovery mechanism for groups/channels. Public Twitter lists could work like this (although you wouldn't be able to make your own modifications very easily) if there was a better way to find good ones.

mthurman commented 11 years ago

Messaging (http://developers.app.net/docs/basics/messaging/) and Channels (http://developers.app.net/docs/resources/channel/) should fill this need. For any more specific issues, please feel free to open a new issue.