Follow has more than one meaning here.

The /follow command

Solid: PSYC user agents (be it psyced or clients) provide a command or graphical user interface that lets you follow an invitation.

We should also provide automatic following based on the idea that we have a trust network, so we trust our friends to put us into contexts we should be. A similar concept also exists in channels, only in that case the trust is implicit with the basic context subscription - so should we implement channels, we can always do quick auto-followed ad-hoc chatrooms with our friends within our own identity's context.

Followers rather than friends

In microblogging it has become popular to simplify the social network concept of friendship into mere followership.

Liquid: psyced supports experimental followerships. See Microblog for details. Instead of having a complex friendship negotiation in order to become elegible for trust and presence notification you can simply enter a #follow channel in a person's entity dedicated to PSYC-based microblogging. By default you should be let in, yet the person has the possibility to move you into a different channel or kick you out.

This is basically like having a place for each person, and in fact implemented that way, since each person may prefer a different kind of moderation approach to discussions happening in reply to her tweets. Allow followers to discuss freely, or rather, send all replies to the owner only? Let friends start threads on behalf of the owner? A myriad of strange configurations are possible.

Hierarchy/naming discussion

<lynX> It has been discussed if status updates should happen in a subcontext called #status or #update, but there are three reasons not to use this vocabulary:

1. status has different semantics in PSYC
2. pretty much everything that isn't status in PSYC is an update, so the two words are oxymoronic within PSYC semantics
3. we need more fine-grained options anyway

So my next proposal would be to have #friend, #follow and #world by default and let the user create further subdivisions by grouping contacts into #family, #work or whatever she finds most suitable (in particular consider that the names of such roster groups are visible to the people inside, so you may want to avoid channel names such as #exboyfriends). The difference between #follow and #world would be, that while #follow still has a minimum degree of privacy #world may be published to anyone anywhere - thus typically gatewayed to non-privacy tools such as Identica or Twitter.

Some things are still suboptimal about this plan: The names I suggested are semantically hierarchical, so those hierarchies should probably be implemented, even if it makes the uniforms uglier. If #follow is a subset of #world, should it be #_world_follow (or #world/follow depending on whatever syntax we pick)? From a routing perspective making a distinction between followers and world actually isn't necessary. The difference is in the semantics. Having a #world channel name can be a way for the user to submit things differently, but distribution should go to the normal followers context, maybe with a _public flag or method extension.

Next question is, are friends a subset of followers? Would it have to be #follow/friend? The downside of this is, you can't send stuff to your followers without having your friends take part of it (you can still have a friends channel which is not a subset of followers, but it doesn't sound like a good idea, since a friend could become your follower by using some anonymous extra identity). The upside is, all followers reside in a single multicast context. We don't want you to send the same packet to two or more contexts. Before it becomes a habit you should always reorganize your channels in order to have all the intended recipients in a single subcontext.

What do we do with friends who want to stay friends but not receive your updates? What about updates that are important enough for friends to receive even if they don't appreciate your day-to-day updates? Should we tag updates with importance degrees and have contexts in an importance hierarchy? So if you subscribed notices of importance degree >0.5 you may find yourself in #friend/9/8/7/6/5 making you receive updates of degree 0.777 and 0.999 etc.

Language support

<lynX> What about language choices? Multilingual people should post things into language channels. Multilingual receivers should be added to all subcontexts of languages they understand? What if the person posts the same story in different translations? Then you would only want to send the best language match to the multilingual folks. Where do we put language choices into our channel names? #follow/fi or #fi/follow? Recipients would provide _language when subscribing, then the identity would have to organize the person most suitably into its contexts, so we can leave it to the server, the client or even the user manually to figure out the best strategy. Tricky tricky.

Solidifying thoughts

<lynX> So what do we do in protocol speak? We send subscription requests with _language_accepted, _degree_importance and of course _tag. The tag is used to confirm the subscription to the base context which, even if unused, is always needed to ensure that further channel operations are legal. Then we return further subscription acknowledgements for each suitable subcontext. You may also employ redirects, but the extra round trip isn't really necessary.