On Wed, Sep 18, 2013 at 2:11 PM, Melvin Carvalho
<[email protected]>wrote:

>
> On 10 September 2013 19:45, Nick Jennings <[email protected]> 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 <
>> [email protected]> 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<http://en.wikipedia.org/wiki/Activity_Streams_%28format%29>project,
for example, is an effort to develop an activity stream
protocol <http://en.wikipedia.org/wiki/Protocol_%28computing%29> to
syndicate activities across social
Web<http://en.wikipedia.org/wiki/Social_Web>applications.
[2] <http://en.wikipedia.org/wiki/Activity_stream#cite_note-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

Reply via email to