PSYC channels.. where no chat system has gone before..

The principle of channels works as such: every group or room can define subchannels of itself and it has the right to make you a member of it, or not, if you have chosen to join the thing as a whole. So it can for example create a subroom of only sports-interested members anytime, and just start using it.

See Spec:Entity for ongoing specification efforts and context for channels in action. See hashtags and followers for applicative ideas for channels.

In XMPP terms PSYC channels encompass concepts like pubsub and roster groups into a single interface (and data structure), plus additionally extending chatrooms.

Diaspora has a roughly similar concept called aspects, although it probably has no relevance in Diaspora's routing. Google+ features circles, but you can't choose which ones you'd like to join – they are only outgoing.

#define channels

See Spec:Channel for the basics.

Looking at the routing infrastructure, a channel is to be interpreted as a new context whose membership structure has to be redefined. At this point, it becomes clear, that the context slaves, which are created bottom-up from the leaves of the multicast tree won’t be enough in order to implement channels, as channels like to be defined top-down from the context.

It is not easy to address this problem. We could duplicate the slaves and tell them which people are still members or we could send out an invite to all the members concerned, so that they create a new context slave tree bottom-up.

Another way could be to implement _members directly as routing information. The remaining question is, how to build the tree — no, this isn’t even what we want, because we may not like that every context slave sees who all the other members (friends for example) are.

So, to enter the leaves is the right starting point, that's also the way how IP Multicast works, if i recall correctly. The list could be pretty useful for routing, in rooms where we it is not secret. Thus _member list could make sense either in entity or in routing varspace.

Contact groups, like the Jabber roster groups, are also a case of application for channels.

Additional thoughts:

       ? should places be able to have several variants of multicast-groups
         (present, logged in, away, all, etc)
         -> thus complete their psyc-contex-urls different
            @wolfa#all @blog#announce @heise#announce
         -> @spiegel#sport, @spiegel#auto, @spiegel#panorama ?
         or do applications need to clone a bunch of places for themsevles?
       ? can the user sort his friends in #family, #idiots, #ignore ?
         will he become a multicontext place himself, that people want to subscribe to?
       ? should you be able to subscribes friends like an /enrol, if they are okay with it?
       ? Are the differentation of /subscribe /notify /friend a problem and 
         are ppl&profile = subscriptions? friends = places? .... YES
       ? should there be a delayed autojoin? and ignore rooms?

And here's just a wild idea for some sort of presence maths:

       ? if you use a value in the range of 0.00-0.99 for presence, then the
         user could provide a base-value (0.60 = 6 = busy) and when this gets rounded/cast, 
         user.c adds for every buddy group a revelant value (+0.22 #friends, -0.44 #ignore) 
         and sends then — if at all — the corresponding presence for every channel … so @psyc 
         gets a presence-update having tha value 0.82, thus AVAILABILITY_TALKATIVE, if it is in #friends
       ? ha!, thanks to _state we can multicast the relative priority changes, 
         even if the targets got assigned different values at the start. 
         That would mean, 0.60 is 0.77 for one and -0.15 for the others, if they are 
         being told at all. (not at negative-values, as it wasn’t planned in the presence-spec).
       ? rooms can classify their output into different levels        
         regular talk starting at +0.70, news/announce only above +0.40 … and the users 
         can classify them accordingly in their context#channels, how sexy is that?! 
         A chatroom that you don’t need to leave because it keeps its 
         mouth shut if you have no time for it.

multilanguage channels

<kuchn> depending on the origin of the user host, one will be directed into an accordingly language-specific subchannel. The same room name for all, but you only meet people speaking your language.

<lynX> I would rather do a language negotiation on the side of the UNI, but apart from that channels for languages are a very good idea.

<coyo> would be a neat option, for things like freenode.

FAQ channels

Channels are an innovative concept, despite the name being similar to the IRC one.

inheritance

heldensaga asks: Do you have to be in @spiegel if you are in @spiegel#sport?

Yes. Conference control would be applied in such a way that @spiegel is typically mute while @spiegel#talk could be open for chat. #sport is politically speaking in the same room, distributionwise however in a different context.

In the end-to-end context, master and participant have to act, as if all channels belong together, thus, when fippo says that you are a member of #bestfriends, than you are lucky and this is good. Technically, a new context, thus a new multicast channel will be built, but it is not clear yet, if the implementation would use the existence of an other context as a blueprint or act differently.

This can be seen as some kind of "forced invite/join," but really it is as natural as someone making a list of phone numbers to send an SMS to. There are no invalid context breaches. Just this little difference allows for new creative applications, since the receiving entities know who they are receiving this from - unlike with SPAM.

slash dash channels

heldensaga asks: el and me want services(/rooms) as part of users and rooms,
thus it should be thought about @spiegel/@sport or ~fippo/@bestfriends
because we wanted to do ~user/$service

the #-character expresses how different “views” are. Parts of the whole. But the arbitrary sub-grouping and sub-serviceation could be useful, have to think of scenarios.

heldensaga asks: psyc://server/#sport can’t exist then. or can it?

I dont see why the server root needs to have a channel, but it doesn’t need to be forbidden.

heldensaga: we use /~lynx$sharing for services, but thats eeww

Yea, something like that is already included … what is eeww about that? Our microblogging feature in psyced is implemented as a subchannel of the user entity.

redirect #trolls

How can a user subscribe multiple channels of a sender?
Does the sender decide about everything?

Say a user would like to receive multiple channels of a particular entity, it can request to enter or subscribe these, but the entity can disagree with this and send the user elsewhere instead.

Imagine going to a disco club. You issue a _request_context_enter for the #vip-area, but what you get back is a _notice_context_enter to #prole-zone. If that makes you angry, you can leave the @club as a whole.

You can choose not having to deal with an entity at all, but if you do, she gets to decide how.

inheritance again

heldensaga asks:
  when i want to be in @wikileaks#news but somebody says something
  in @wikileaks, do i get that?

Yes, anything in the top context goes out to all subscribers of any subcontext, that's why we will see less places and few people allowing for chat in the top level.

heldensaga asks: will this be merged? like when i am in spiegel#sport
 and spiegel#panorama. will i have two windows for that?

That's up to the client to decide, but i would rather have them all merged under the name of the entity. you will receive the channel's uniform in the sending _context.

Specifically in the case of the IRC interface I would just strip the channel extension so what you get looks like what is happening on that channel. That's an amazing new way to experience IRC, if every person gets her own view of a channel, since they are no longer necessarily the same.

channels in chatrooms

It should be useful to have enter/leave-traffic (in channels with large numbers of IRC client users for example) separate from actual communication whereby you can deliberately choose to skip all the coming and going notifications and just receive the actual conversation. This is more refined than having a presence filter in the place and more efficient than having presence filters in the client.

privacy in channel names and roster groups

since we are likely to group our contacts by criteria like work, family, flirts, idiots etc. it is a smart enhancement if there was a user-provided name for the channel that only the user herself sees while to the outer world an obfuscated or random string is used. actually we could be using single letters all across the alphabet. enough in most cases.