Contents |
PSYC? Huh?
Protocol for SYnchronous Conferencing.
PSYC is, as benchmarks show, the fastest yet extensible text-based protocol we are aware of, providing a messaging infrastructure for human conversation and social exchange of possibly binary data. It has learned from protocols such as IRC and XMPP and chose an approach that should scale globally by generalizing the multicast concept beyond programmable chatrooms to presence awareness, event notification, news- and friendcasting. In commercial settings PSYC is also being used for telephony and audio/video. PSYC provides trust metrics for a distributed social graph and publish/subscribe data. In combination with pseudonymous routing technology it turns into secure share, a platform for maximum privacy social networking and applications.
PSYC Meet-Ups 2009-12
<lynX> I was thinking of some place in Kreuzberg/Kreuzkölln.. or simply the C-Base if it has space & time for us. We can meet every day starting the 26th, any time that suits your schedules, and I will also come up with some good suggestions for NYE. So go ahead and suggest some times!
<Marenz> Possible time windows for meetings:
- 27.dec 10-14:30
- 27.dec 00:00-…
- 28.dec 00:00-…
- 29.dec 14:00-16:00
- 29.dec 00:00-…
- suggest your own timewindow, i can cancel most of my events.
<lynX> The night of 29th is bad because of Tini's birthday and Linuxtag side event, but we can do some more tonight, like discuss the team TODOs.
Outcome
We met on the 27th after midnight and on the 28th after 10pm. We discussed the general architecture of PSYC including channels (how not to subscribe presence by default), state (and how to bring clients in sync) and the big rename.
Some changes in vocabulary and understanding were deemed necessary:
- If an entity is a context, the two terms become kind of redundant. We could either drop one or the other. If an entity has a context, it may as well have many. In that case the term channel becomes redundant, since an entity can have as many contexts as it likes, which obviously are in some relationship to each other, which should equal the channels concept.
- So-called entity variables should be renamed into context variables since each subcontext (formerly known as channel) needs to be able to have its own state.
- Would we want inheritance between contexts also applied to state? How would that work? If you install a new subcontext of a context, does it start out using the state of the parent context? [Could be]. Does all of its own state just exist in form of a delta compared to the parent state? [Probably too complicated].