Re: Getting the group back on track

On 16 October 2015 at 13:24, elf Pavlik <perpetual-tripper@wwelves.org>
wrote:

> On 10/16/2015 12:59 PM, Melvin Carvalho wrote:
> > On 15 October 2015 at 18:58, elf Pavlik <perpetual-tripper@wwelves.org>
> > wrote:
> >
> >> On 10/14/2015 09:13 PM, Jason Robinson wrote:
> >>> Hey,
> >>>
> >>> A big +1 the the email of Christopher.
> >>>
> >>>    > Right now, off top of my head implementers would be:
> >>>    >
> >>>    > 1) IBM Connections
> >>>    > 2) Pump.io
> >>>    > 3) MediaGoblin
> >>>    > 4) Objective8 (Thoughtworks)
> >>>    >
> >>>    > Anyone else?
> >>>
> >>> I'm pretty sure if a clear and well thought JSON based language comes
> >>> out, diaspora* is interested. However, AS2 is only the language part,
> >>> personally waiting to see how the protocol parts start to take shape.
> >>> Hoping to have more time to contribute to those stages which imho are
> >>> more important for our use case at least. TBH, the way that objects and
> >>> actions are presented for transfer is only a minor part in the whole
> big
> >>> engine of two servers exchanging messages. For diaspora*, and the
> >>> Friendica + Hubzilla that are connected with it using the same
> protocol,
> >>> the server to server is key.
> >>>
> >>> Personally I hope the language semantics part could be quickly locked
> >>> down and the work moved on to figure out the protocol stuff. There is
> >>> not going to be a "works for all final" version delivered by any group
> >>> ever - everything is always iterated on, and it is better to deliver
> >>> something concise and small first, instead of trying to tackle
> >> everything.
> >>>
> >>> Just a few comments regarding how diaspora* federates. Basically we
> have;
> >>>
> >>> * webfinger and .well-known/meta-info for discovery
> >>> * XML language for actions and content
> >>> * Salmon Magic Envelope for signing the XML content
> >>>
> >>> The project is in the works of pushing out the federation code to a
> >>> separate repository, which means it would be easier to start using
> >>> another protocol in some future. The key things that we need however
> are
> >>> pretty much the three items above;
> >>>
> >>> * discovering
> >>> * describing content
> >>> * authoring
> >>>
> >>> Especially the last one is something that I'd be interested in hearing
> >>> some thoughts about, what kind of idea has this group got on how to
> sign
> >>> AS2 JSON content payloads? Outside diaspora*, I've got some personal
> >>> plans on creating a Python library to abstract several protocols, as an
> >>> experiment if nothing else. Currently it supports diaspora* for some
> >>> limited stuff, receiving and sending posts, and I would like to add
> some
> >>> AS2 based routes there too. Content signing is *the* most important
> >>> thing to get right.
> >>
> >> We had months ago bit intense conversation around JSON-LD Signatures
> >> * http://manu.sporny.org/2013/sm-vs-jose/
> >> * https://youtu.be/QdUZaYeQblY
> >> * https://github.com/digitalbazaar/jsonld-signatures
> >>
> >> I hope to give them a try in near future. Also combined with content
> >> addressable versioning of documents...
> >>
> >
> > Thanks for the pointers.  I use this too.  I first became interested in
> > this back in 2001 when I was the lead developer for implementing digital
> > signatures at Deutsche Bank.  It emerged that there were problems with
> > standard document signing and signing of XML which was problematic in the
> > finance world.  Since that time I've been searching for a solution to
> this
> > problem and LD signatures solves pretty much all problems out there.  Do
> > note that it was designed for high value transactions, so may be overkill
> > for more casual aspects of the social web.
>
> Melvin, as I understand LD Signatures rely on RDF Dataset Normalization
> * http://json-ld.github.io/normalization/spec/


yes, json-ld signatures (jsigs) now has the latest 2015 graph normalization
and signature algorithm implemented. Brian Sletten just implemented the
same in the rdflib Ruby library too. Python and PHP implementations are
being updated

note these are updates as of the last week


>
>
> and while work with JSON-LD in very elegant way, they don't stay JSON or
> XML or RDFa or Turtle specific? One can use them in the same way with
> any of RDF serializations?
> * http://www.w3.org/TR/rdf11-new/#section-serializations
>
>
>
exactly, it can be used with any data, and any serialization ... most
recently I am finding turtle more attractive as it offers advantages, but
the same system works with XML or JSON LD too