* <<G6J.1329>> Microformats, opposed to explicit ActivityStreams
verb/object types
** No New Activity Objects; Microformats Instead
In GNU social, as in other ActivityStreams-based systems, the
activities of users are published as verb:noun (or, action:object)
data pairs. For example, when a user posts a notice the server
publishes an activity composed of a Post action (verb) of a Note
object (noun); likewise, when a user joins a group the server
publishes a Join:Group activity; when a user follows another user the
server publishes a Follow:User activity, and so-on.

Every GNU social server understands a set of core action types —
Join, Follow, Post, Delete, Share, and Favorite — as well as a set
of core object types: Group, User, Article, Note, Comment, and
Activity. However, GNU social is extensible via plug-ins, which may
enable the server to publish new types of actions and objects. The
current stable release comes with a number of plugins (mostly unused)
supporting a variety of Postable objects (Poll, Bookmark, Question,
..), as well as a few special actions related to those types (Vote,
???).

The problems with this approach to extensibility are: first, as GNU
social is written in PHP, plug-ins must necessarily be written (at
least partially) in PHP as well, which may be an unpalatable course
of action for programmers unfamiliar-with or opposed to that
language; second, user activity only propagates between servers that
have been augmented to handle the same action and object types. For
example, if a user posts a Poll on his server, his followers on other
servers which do not have the Poll plugin enabled will not even
receive notification that a Poll has been posted — and they will
certainly not be presented with the opportunity to vote on that poll.

The users of the GNU social network would be better served by a small
set of generic, universally-supported activity types which could be
extended with microformats[1] in their content. The benefits of this
approach are:

1. The server need never be augmented in order to store, retrieve, or
publish any kind of activity. This ensures...
2. ...consistent functional capability across servers. By way of
analogy: your email provider may limit the size of messages you are
able to send/recieve, but there are no limitations on the *types* of
message+attachment which can be sent/received. We should expect the
same kind of content-neutrality on GNU social nodes.
3. The responsibility for handling different types of data would fall
on the client instead of the client *and* server.

[1] I'm using "microformats" generically, here. The microformats
specifications are certainly a good place to start, but with the
introduction of HTML 5, custom elements of the <x-*> type and
attributes of the data-* type provide a powerful mechanism for
defining data objects inside valid HTML. Ideally, all microformatted
post objects would degrade to text so that a client which does not
provide a viewer/interface for a particular object type could simply
display the text content of the object.

-----

I propose that the Article object — which is a core object type
already supported across all StatusNet and GNU social servers — be
used for new post types which would be entirely contained within the
<content> element of the activity object. For example, the Polls
plugin could be obviated by implementing polls as Articles containing
HTML/microformats, such as:

<entry>
 ...
 <activity:object-type>article</activity:object-type>
 <content type="html">
   <div class="h-poll">
     What's your favorite colour?
     <ul>
       <li class="p-option">Crimson</li>
       <li class="p-option">Vermillion</li>
       <li class="p-option">Chartreuse</li>
     </ul>
   </div>
 </content>
 ...
</entry>

Poll responses could simply be Comment objects with free-form
contents, but with the vote selection microformatted in the text:

<entry>
 ...
 <activity:object-type>comment</activity:object-type>
 <content type="html">
   Pretty limited choices. Of those offered, I guess I like <span
class="h-vote">Vermillion</span>.
 </content>
 ...
</entry>

The mechanism for making sure that poll responses are coded as
h-votes (or whatever) would be the responsibility of the client, as
would tallying of the poll. Clients may provide a variety of
presentation or interaction features for microformats they
understand, and fall back to treating articles as simple HTML posts
for those that they do not.

With the server-side plugin system, both the server and clients need
to be extended to handle different activity types. With this kind of
microformatted content inside generic Article objects, only clients
need to be extended.

** Deprecate "Favorite", implement "Tag"
Favorite is a very specific activity, and one that invites the
question of why there is not a corresponding "Hate" activity.

Functionally, Favorite adds an activity to a list of favorites. The
question raised by that is: why do we only have one special-purpose
list? Why not an infinite number of lists?

Now, I realize that *I just recommended* that no new activity types
be added, but this is a special case because.

+The next question is: do we need a new Tag action? Or, could we
simply use the Share action.+

+A tag action would be useful as each tag would be its own database
record, and users could tag/untag activities as they+  +sers need
only Share a post with tags added to the <content> of their share.
not only could we enable extended functionality like galleries or
"pinboards", but we could obviate the Favorite action while providing+

** Deprecate the Share activity?
- Could be obviated in two ways:
- 1. Post a new notice that links the old one as an attachment.
- 2.

- The immediate obejection to the first approach might be that it
starts a new conversation thread, disconnected from the original
notice.


No new post types on the server; all post contents are XML,
implementing microformats

-----------
Follow, Unfollow -> User
Join, Leave -> Group
Post -> note, comment, article, +poll, bookmark, question, etc...+
+Favorite -> Activity+
Tag -> Activity
+Repeat -> Activity+

--
Excerpted from:

PUBLIC NOTES (G)
http://alph.laemeur.com/txt/PUBNOTES-G
©2016 Adam C. Moore (LÆMEUR) <[email protected]>

You are viewing proxied material from sdf.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.