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

[Melvin Carvalho]

On 19 September 2013 21:51, Nick Jennings <address@hidden> wrote:

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

On 18 September 2013 18:06, Nick Jennings <address@hidden> wrote:

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

On 18 September 2013 15:47, Nick Jennings <address@hidden> wrote:

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.

"Depending on who you speak to" is hedging your bets a bit!

I was speaking to you, what's your take?  Is activity streams a protocol or not?

I'm more interested in my original question, not whether AS is a protocol or not. Like I said, I don't have a strong opinion either way.

OK, then why did you argue the case?

I'm not arguing any case, I just pointed out that many people, including the OP and Wikipedia refer to AS as a protocol. I really don't care what people call it. Maybe you could ask Carlo why he chose those words.

HTTP is the protocol, Activity Streams is the serialization.  A (communications) protocol is way more complex than a serialization. 

I'm fully aware of the differences between serialization and protocols.

 

And if this is what you want to do with sockethub / activity stream, I think you're going to run into major issues.

My comment was that the Activity Streams specification does not mention encryption anywhere.

You are the person that said: "being distributed and/or encrypted is something that can build on-top of the existing protocol" ... "something I'm working closely with in Sockethub"

I have doubts about this comment ... how do you intend to build encryption on-top of Activity Streams?

You have doubts that I'm working closely with implementing encryption wherever I can? I'm sorry to hear that, but I asked my original question to perhaps gain some insight into what shortcomings AS has in regards to being implemented in a distributed, encrypted infrastructure.

i asked how you are working to build encryption on top, in line with our claim

 

As in, what characteristics about a protocol or serialization method lend itself to encryption or make it more difficult, and why does it really matter what a payload is within an encrypted channel.

I think it should be considered with care when deciding to re-implement something that already exists, like AS, to serve the same purpose. So I was curious as to what the thought process was, and asked the question in the hopes I might learn something new.

I don't really want to continue to get caught up in semantics with you about wording of protocol vs. serialization, as it's completely unrelated to my question.

 activity streams itself is a reinvention ... you are saying pick one reinvention over another and at the same time not to reinvent ... it's a contradiction

 

Cheers
Nick