Re: [GNU/consensus] [SocialSwarm] Why secushare's new pubsub & multicast API could spell revolution

[Nick Jennings]

On Wed, Sep 18, 2013 at 2:11 PM, Melvin Carvalho <address@hidden> wrote:

On 10 September 2013 19:45, Nick Jennings <address@hidden> wrote:

Hi Carlo, nice to see this work being done, specifically a distributed pubsub implementation. Do you have a repo where this is being developed? Also is this just the beginning or is there something working already?

One question regarding ActivityStreams below:

On Tue, Sep 10, 2013 at 6:41 PM, carlo von lynX <address@hidden> wrote:

At the same time as the implementation of this fundamental piece of the GNU Internet is taking place, we will soon present the equivalent of the ActivityStreams protocol, enabling developers to create user interfaces and further applications on top of an infrastructure that provides similar social functionality as the social services we are familiar with, but in a distributed and encrypted fashion.

I'm unclear why it makes sense to re-invent the ActivityStreams protocol? There is nothing in it's nature that defines infrastructure, so being distributed and/or encrypted is something that can build on-top of the existing protocol, also something I'm working closely with in Sockethub.

Activity streams is not a protocol

That depends on who you ask, from the Wikipedia page:

    " The Activity Streams project, for example, is an effort to develop an activity stream protocol to syndicate activities across social Web applications.^{[2] "}

While I agree there's more to a protocol than just the data format, there's definitely work being done to make the content of the AS objects indicate either intent or result, which lays the groundwork for a protocol.
 

It's a data serialization.

While basically true, I'm not sure that's a descriptive enough word, as JSON itself is a data serialization method.

I was using the same words Carlo used to reference it, and I don't have a strong opinion either way, but I don't think using the term serialization makes it any clearer.

The current version relies on a proprietary central registry of verbs which does not (currently) support any form of encryption as far as I know

If AS is a protocol, then I don't understand why a definition of verbs should be considered proprietary or centralized - in the same way that any other protocol, be it HTTP, SMTP or FINGER, has a set of defined commands.

If AS is a data serialization mechanism, I don't understand how it can written it to "support for any form of encryption". Are the two related? Does JSON itself have built in support for encryption that AS lacks? Could you give me some examples of data serialization which supports encryption?

Maybe I misunderstand what is meant by the original statement by Carlo, but that's why I asked in the first place.

Cheers
Nick