Developing a Distributed Model
Ryan Altman
aligned with decentralized/distributed micro-updating.
Briefly (where I stand),
Early in April I set out to create an activity stream, but soon
realized that allowing small messages to be appended to each activity
item created something like status-update, so I allowed it and it
became something like scrobbling with text, something not directly
possible with twitter or any status-update. Eventually, the
implementation was shifted to an inbox-model, as opposed to joining on
the friends table. This was an important move with regards to allowing
distributed domain interaction.
One of the large goals early on was for these activity streams to be
interactive between domains, or interactive between users regardless
of which service the user belonged to; federated. I didn't start down
that path until late Summer, and when I decided to start modeling the
concept, I came to understand the OpenMicroblogging protocol, or at
least the most important aspect of it.
OMB is a great start, but the primary issue I had with adapting it to
mix my own activity concept is that the protocol is confined; there
are too many required parameters, and adding more in extension is
crazy. What is highly important in OMB is exactly how "following"
relations are made between users/domains, and that is via sharing an
OAuth key with the publisher.
As I generalized my specification, I realized that the greatest
concern is not the data-model (what the data should look like, ie the
format of a twitter <status>) but the method of establishing follower-
followee, publisher-subscriber relations. Sharing OAuth keys in the
same manner as OMB is massive imo, as it allows "friending" regardless
of usership on a given domain. (Some might say OAuth is not required,
but it prevents spoofing to inbox, so to speak)
So with the ability to establish relations, where a publisher has
direct access to put an update in a subscriber's inbox, I began to
consider the data-model. Soon it became apparent that specifying less
has a huge advantage over OMB, which requires a number of REST params.
I decided to go with one primary parameter, packet, which is an xml
structure containing whatever has been established between the users.
A packet has a general format and content requirements, but they are
quite limited and appear similar to a <status>.
<fp>
<id> -- local id (on originating domain) -- </id>
<global_id> -- creator/user's update id (allows importing/exporting
profile to other domains as it is unique across the internet) -- </
global_id>
/* CONTENT */
<user>
<name> -- nickname/handle -- </name>
<domain> -- domain of usership -- </domain>
</user>
</fp>
If the <id> and <global_id> are not included, the packet is treated as
a "notify" and should not be stored among subscriber nodes (there is
no permanence). Notification allows things like profile-updates,
bumps, nudges, etc.
The above is a skeleton. In the implementation, elements such as
<text> are used, but not required be the specification. I am also
using <gravatar_md5> in the <user> element for profile pics. The
original activity stream data is basically a separate xml element,
<action>, but it is not required of the specification.
My own implementation insists on modifying/rendering the packet
contents via plugins which hook into the process flow of publishing
(similar to Wordpress plugins).
I have found that partially specifying allows both translation to
twitter's <status> format as well as allowing users to dynamically
determine just how packets can be used; the underlying distribution
architecture remains.
I hope this helps in modeling the goals of this group.