Re: Matrix's spec and the SocialWG

I'm going to note that I think the Matrix stack of specs needs some more
work, but if pretty solid work and a great JSON replacement for XMPP. To
see it go standards track and merge in with the existing work on
ActivityPump/IndieWeb would be great, and we should at least try to
align the specs if Matrix doesn't have the time, just as we should do
for SoLID.

   cheers,
         harry


On 07/26/2015 02:09 PM, Amy G wrote:
> Hey Chris,
>
> What a great coincidence. Matrix sponsored this weekend's IndieWebCamp
> Edinburgh, and one of their developers, Kegan Dougal, attended. He
> turned Matrix into a Micropub client in one day! All of the 'test'
> posts on the front page of my site at the moment (to be deleted) were
> sent with Matrix.
>
> Amy
>
> On 26 July 2015 at 18:35, Christopher Allan Webber
> <cwebber@dustycloud.org <mailto:cwebber@dustycloud.org>> wrote:
>
>     Hello all!
>
>     I had the good fortune to speak to some of the Matrix authors at
>     OSCON.
>     I hadn't realized how interesting their work was, and how close it was
>     already to some of the work we're doing.  There's a "living
>     specification" up:
>
>       http://matrix.org/docs/spec/
>
>     At present, the canonical Matrix implementation looks very similar to
>     what's being done in ActivityPump especially, in that it's mostly
>     about
>     pushing around json snippets.  However, there are some differences:
>
>      - There are "rooms" which sounds very chat-room-oriented, but in
>        reality is very similar to ActivityStreams streams.  Rooms have an
>        ACL attached.
>
>      - Rather than Activities, there are Events, but they're similar
>     enough.
>
>      - There are a lot more endpoints at present than in ActivityPump.
>
>      - There is no single server controlling a channel of communication!
>        This was really interesting to me.  You can have multiple servers
>        connected together via WebRTC or the like.
>
>      - Of course, that immediately leads to the question: how is a
>     stream of
>        data represented?  In this case, a room's data is not a list/queue,
>        it's a directed acyclic graph, like git or a blockchain. 
>     However, it
>        is possible within the protocol to only pay attention to the DAG
>        after a certain point... there is no requirement to keep a full DAG
>        around for a room to participate, in case you wish to drop old
>     data.
>        (Anyway, depending on the ACL of the room, you may or may not have
>        access to the past history of the room before you joined.)
>
>        I *really like* this feature!
>
>      - It looks to me that the ActivityStreams spec is a lot more clearly
>        defined, as is mechanisms for extensions, but "java-style
>     namespacing
>        is possible".
>
>     The current canonical implementation is written in Python and Twisted,
>     but a rewrite is being considered.  Despite some performance issues
>     which seem resolvable (for instance, data is currently being
>     serialized
>     from json to a string and then written to an SQL database; not the
>     most
>     efficient representation, something like jsonb in postgres might be
>     considered for the future, though the protocol is not tied to this of
>     course.)
>
>     The person I talked to (Matthew Hodgson, technical lead) wasn't
>     interested in investing the time in social working group participation
>     but would still be interested in collaboration... I suggested maybe I
>     could be a liason between the working group and Matrix, and keep
>     Matrix
>     updated of things of interest to them as they may happen, and
>     hopefully
>     vice versa.
>
>     Thanks all!
>      - Chris
>
>