[liberationtech] Have any of you ever used Scuttlebot?

[fuzzyTew]

It sounds like an implementation of the secure scuttlebutt protocol
requires a json parser that preserves ordering of object keys in both
directions.

On Tue, Apr 21, 2020, 2:44 PM John Ohno <john.ohno at gmail.com> wrote:

> Sorting the keys is absolutely a component of the solution, but doing so
> makes the format functionally not standard JSON, & also means that code
> needs to be injected into third party JSON libraries. JSON, as specified,
> does not define key order, which makes any variation of JSON that cares
> about, exposes, or allows you to control key order not really JSON.
> Libraries aren't required to expose this, & so to the extent that they do
> (ex., the JSONSimple library in java) it's a side effect of an abstraction
> leak (like preserving insertion order) & can't be relied upon not to change
> in some future release -- which adds maintenance headaches, since a change
> in a third party library can break your implementation.
>
> On Tue, Apr 21, 2020 at 11:49 AM Steve Phillips <
> steve at tryingtobeawesome.com> wrote:
>
>> > Fully independent implementations are under development, but they're
>> difficult because the protocol as defined involves cryptographically
>> signing sections of regular JSON -- which, of course, has no defined order
>> for objects. This means that in practice, the SSB protocol is not standard
>> JSON plus signatures, but the entire set of nodejs JSON serialization
>> quirks.
>>
>> SSB doesn't sort the keys first to ensure the JSON serialization is
>> simple and deterministic?
>>
>> --Steve
>>
>>
>> On Mon, Apr 20, 2020 at 9:40 PM John Ohno <john.ohno at gmail.com> wrote:
>>
>>> I have used scuttlebutt for a few years. Unfortunately, in the past
>>> month or two, I've found the clients a lot less reliable, so I haven't been
>>> on very much.
>>>
>>> SSB has an interesting culture. The developers are very concerned with
>>> the social ramifications of offline-first & truly-peer-to-peer
>>> communication, and are seriously discussing (and making technical decisions
>>> about) the kinds of media theory issues that get only idly discussed on the
>>> fediverse (and almost not at all in centralized social networks). For
>>> instance, SSB functionally has transitive blocking, & this lowers the
>>> moderation load on individuals, who are simply inaccessible if the number
>>> of hops between connections is too high.
>>>
>>> I don't know how good SSB's *privacy* features are. From what I can
>>> tell, they aren't very concerned with that, as compared to
>>> anti-falsification (which is functionally just necessarily for good p2p in
>>> an offline-first setting). There are private message systems, but I haven't
>>> used them (let alone security-audited them).
>>>
>>> Fully independent implementations are under development, but they're
>>> difficult because the protocol as defined involves cryptographically
>>> signing sections of regular JSON -- which, of course, has no defined order
>>> for objects. This means that in practice, the SSB protocol is not standard
>>> JSON plus signatures, but the entire set of nodejs JSON serialization
>>> quirks. In order to implement it in another language, you have to duplicate
>>> exactly the ordering produced by nodejs, or else old messages will not be
>>> interpreted as valid by your implementation and the messages produced by
>>> your implementation will not be interpreted as valid by competing
>>> implementations. Ultimately, this means that if you want a full-featured
>>> SSB client, you're stuck with an electron app (with all the attendant bloat
>>> and memory leaks).
>>>
>>> On Mon, Apr 20, 2020 at 2:52 AM Daniel Bosk <dbosk at kth.se> wrote:
>>>
>>>> No:
>>>>
>>>>   https://ieeexplore.ieee.org/abstract/document/6197506
>>>>
>>>> One must design it carefully. But if done right, it's really nice.
>>>>
>>>>         Daniel
>>>>
>>>> On Sun 19 Apr 2020 01:24:02 GMT, Yosem Companys wrote:
>>>> > P.S. Is P2P inherently more or less secure than the alternative?
>>>> --
>>>> Liberationtech is public & archives are searchable from any major
>>>> commercial search engine. Violations of list guidelines will get you
>>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
>>>> change to digest mode, or change password by emailing
>>>> lt-owner at lists.liberationtech.org.
>>>
>>> --
>>> Liberationtech is public & archives are searchable from any major
>>> commercial search engine. Violations of list guidelines will get you
>>> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
>>> change to digest mode, or change password by emailing
>>> lt-owner at lists.liberationtech.org.
>>
>> --
> Liberationtech is public & archives are searchable from any major
> commercial search engine. Violations of list guidelines will get you
> moderated: https://lists.ghserv.net/mailman/listinfo/lt. Unsubscribe,
> change to digest mode, or change password by emailing
> lt-owner at lists.liberationtech.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ghserv.net/pipermail/lt/attachments/20200422/1dc61fd2/attachment.html>