Activity Streams Base Schema
Mapping of activitystrea.ms' base schema to PSYC. Activities are notices in PSYC. They have an Actor which is the _context routingwise, a Verb which is a derivate method of _notice, an Object which is specified in various variables and a Context which isn't a context in PSYC's sense but rather extra information such as a timestamp, a geolocation (address) or a mood.
Here's an example of how it looks like in PSYC syntax to send a video clip to a channel of subscribers, indicating that you like it and that it cheers you up (The aligned whitespace is a cheat for readability – actually we use a single TAB character on each of those lines).
| :_context psyc://<your-host-key>:g/~sammyjoe#_fun =_degree_mood 7 =_action rolling on the floor about this :_title_media_video My pig whistles the theme tune of Bonanza :_image_media_video <some binary data here> :_degree_appreciation 99 :_page_media_video http://example.com/v/wKlHQBhOIX4 _notice_mark |
Not exactly typical, as it is unlikely that a user would like a video while also writing a /me to it and choosing a new mood level.. but hey, just in case.. some people love to spend time on making their social activities really fancy and inviting.. right?
As you see for this kind of procedure the variables aren't stored into the distributed state, as there is no need to maintain a notion of your 'currently liked video.' The activity is simply stored into the channel's distributed history which is a more volatile kind of storage (you only keep as much of it as you care to and you can ask for old slices of it at the source or at other subscribing or relaying nodes).
For the following things, you can deduct how it should look like - when the time is right we shall refine this into an obvious to use specification.
3.1. Base Verbs
These "base verbs" are event notifications generated by a person entity to be sent to its contexts, be it private (friends) or public (followers).
3.1.1. Mark as Favorite
Map to _notice_mark with _degree_relevance [0..9]+
3.1.2. Start Following
3.1.3. Mark as Liked
Map to _notice_mark with _degree_appreciation [0..9]+
3.1.4. Make Friend
Announce that we completed a friendship negotiation with somebody (if you know the person you should get a confirmation from her, too): _notice_friend_made with _uniform_friend.
This would be a _notice_context_enter. See context.
We already have _notice_play_music_title in psycmp3 but a generic _notice_play makes more sense here. See below for object types.
isn't properly defined apparently. The onesocialweb draft has this featuring an object as provided below. Here's an example of "post" with a "status" object as a PSYC packet equivalent to the example featured in the draft.
:_context psyc://denmark.lit/~hamlet#_follow :_subject to be or not to be ? :_type_content text/plain _message to be or not to be ? |
Huh? Who wants to know?
I'd like to think of something better than _notice_tag.
3.2. Base Object Types
- _description_article (a summary usually)
- _uniform_audio (or _stream ?)
There's also a special event type for audio that is known to be music.
- _uniform_image_bookmark or _image_bookmark for actual embedded binary image data
Actually what we need here is a _thread id. See threaded discussion rooms.
According to file transfer this would be _notice_available_file with
but it also makes sense to share the file directly or even embed it.
Make sense to call this _notice_available_folder although it isn't entirely clear why the directory listing should be transferred by HTTP if it can be a _list_uniform.
- _uniform_image_list_folder or _image_list_folder for actual embedded binary image data
Folder would be a derivate of List below.
- _uniform_image_group or _image_group for actual embedded binary image data
but.. ahem.. where do you put the actual _uniform_group !?
- _page_list but a _list_uniform would be better
Message body belongs into the body of course.
- _uniform_image or actual _image data
Haha, again they forgot the most important information.. the _uniform_person. You may want to provide some _size_image or the actual binary _image data.
- _uniform_image_small or _image_small for actual embedded binary image data
- _uniform_image or _image for actual embedded binary image data
3.2.12. Photo Album
- _uniform_image_list_image or _image_list_image for actual embedded binary image data
- _uniform_image_list_media or _image_list_media for actual embedded binary image data
but of you could have a _list_uniform_media with the actual items...
Oh yeah, great idea. Let's enforce SPAM marked as SPAM so we can automatically ignore it.
- _uniform_image_product_small or _image_product_small for actual embedded binary image data
- _uniform_image_product or _image_product for actual embedded binary image data
- provide the packet id of a previous _notice_share_product or provide all the variables for a _product as defined above
- _uniform_image_service_small or _image_service_small for actual embedded binary image data
- _uniform_image_service or _image_service for actual embedded binary image data
This could be considered a presence announcement:
Of course it doesn't have an associated _page in a world of real chat systems. Or it could be a _message posted to the microblogging channel, in that case a _message with a body and optionally a _page would do.
- _uniform_image_media_video or _image_media_video
3.3. Base Activity Context Elements
See address and Place above.
This needs packet ids in a _reply variable.
4.1. Event Verbs
4.1.1. Positive RSVP 4.1.2. Possible RSVP 4.1.3. Negative RSVP
_notice_calendar_attendance with _degree_attendance where 0 = no, 5 = maybe and 9 = yes.
When sending out such an event it makes sense to also provide the calendar data, thus it is a derivate of _notice_calendar
4.2. Event Object Types
Here's the _notice_calendar:
Oops, they left out the _page_calendar!
5.1. Music Object Types
What about all the other Audio information?
Extending the ActivityStreams namespace
It's nice about XML namespaces how they can by definition never collide, but this degree of engineering perfection causes us a lot of overhead, making ActivityStreams very large when rendered in RDF and XMPP. When doing custom extension in PSYC, the approach is to just extend the name of the method - as long as people use differing method names, protocol extensions can exist next to each other happily. Method name unicity cannot mathematically be ensured, but it's enough to append your company name to make it unlikely for anyone else on earth to have the same name. How this kind of safety is delivered when using the JSON syntax of ActivityStreams is unclear. Apparently it was no longer an important design criterion, so using the JSON encoding of ActivityStreams may cause trouble at a later time.