Re: sockethub Re: Federation protocols

Thanks for the summary Melvin, that's a good synopsis. I just want to add
that the JSON objects used in Sockethub are actually more loose than to be
based off v1.0 of activity streams. We just decided to model the approach
after the idea of Activity Streams without getting into any details. The
verb list I've been using, for example, has been off the "activity schema"
draft.
http://activitystrea.ms/registry/verbs/

So, it's "neither here nor there" in terms of version number, but I plan to
fix this as Sockethub matures, and more strictly follow the schema for
AS2.0.

Cheers
Nick



On Sat, Jun 1, 2013 at 4:05 PM, Melvin Carvalho <melvincarvalho@gmail.com>wrote:

>
>
>
> On 31 May 2013 16:25, Andreas Kuckartz <A.Kuckartz@ping.de> wrote:
>
>> Michiel B. de Jong:
>> > On 2013-05-31 15:42, Andreas Kuckartz wrote:
>> >> This is a polyglot gateway, correct?
>> >
>> > i'm not sure what you mean, useraddress.net is not a gateway, it's a
>> > search engine.
>>
>> I see, sorry.
>>
>> >> Would it be possible (and reasonable) to use the same approach for
>> other
>> >> protocols?
>> >
>> > other than what? the idea is to build something that can communicate
>> > with all the cliques out there. useraddress.net does that for user
>> > search, and sockethub does it for messaging. can you give an example
>> > of which other protocols you mean?
>>
>> Thanks for mentioning http://sockethub.org I still need to have a closer
>> look at that. It seems to be close to what I have in mind.
>>
>
> Sockethub is a pretty good system, I know Nick personally, and we've
> talked about it a lot.
>
> Currently, it maintains a registry string pairs of "platform", "verb" and
> then provides an API which talks to other APIs.  The format is loosely
> based on Activity Streams 1.0.  I'd love to see embracing of an Activity
> Streams 2.0 approach, which might fit well, as Michiel (who I met last
> month) also loosely bases a lot of his work on JSON LD.  The slight
> downside is that registries can be a challenge to maintain, but these
> things can potentially be fixed in future.
>
> It's a useful project, and I think one that would benefit from
> standardization and/or the best practices doc.
>
>
>>
>> Cheers,
>> Andreas
>>
>>
>