New blog entry. DRAFT - NSYNC - a way to create a distributed trust network based on content and updates. Replies here will show up as comments on the blog - sorry Twitter friends, that's a only feature.

Small Update: If you have ideas, suggestions - I just created a new mostly empty git repository at to work on the concept a bit more. Yes, it has an RSS feed :)

@jwildeboer That's kind of what is going on with @interpeer, except not quite, and not yet. But for much the same reasons.

The first difference is that we're not having IDs for anything quite as granular as a line or something. That's something of an optimization of the ID space on the one hand, but also it doesn't really matter, because of another thing I'll get to in a moment.

The second thing, which is kind of important, is that we're not using UUIDs, but IDs that are..

@jwildeboer ... deterministically created, but not based on content hash. Instead they're based on author and predecessor hash, so kind of block-DAG-y, but without any of that blockchain bullshit. The rest is fairly similar wrt IDs and content bits.

The major difference, though, is that each IDd piece of content contains sections that encapsulate CRDT operations. Now we could use the simplest of operations, "append a line with content X", and you'd get to very much the...

@jwildeboer ... same result. But we can also have more complex, and even content type specific operations. @alcinnz is experimenting with, by way of example, audio sample editing.

The downside is that you have to do some local processing when syncing all the bits from everywhere, but the upside is conflict free multi-authoring. Which is a huge upside, if you ask me.

(Which raises the question of authorization for that.)

There's some PoC, but we're still...

@jwildeboer @alcinnz ... a little away from a demo. But getting ready to demonstrate at least parts.

@jens In my view of the digital world there is no absolute claim to ownership, just claims. Claims that my peers can trust by adding their stamp of approval. For verifiable credentials in modern digital ID lingo. There's should NEVER be an single authoritative entity IMHO.

@jens It's what the world seems to be build on. I question that. And am looking for better solutions.

@jens Which is why I propose to have UUIDs and hashes separated. You can claim whatever you want, but verification becomes distributed used and P2P in my view.

@jwildeboer Yes, much the same here. 🤷‍♂️

I think we're working from different assumptions that are currently unvoiced, but it's late, and maybe not the best moment to go deep into that. We should, however, because I think we're pretty much on the same page here.

Maybe we can find a chat or phone tomorrow?

@jwildeboer I had a much busier day than I expected now. But I don't really want to let this go. I suppose best week, then!

@jwildeboer Interesting, thanks! I'd say this is way to map an existing trust network (of your 'peers' - whatever that might mean) into the digital domain, in much the same way as GPG key signatures work (or generally fail for the wider community), and will have similar issues with the existing trust network being hard to define and new trust being hard to obtain.. it's a human problem first and a technical one afterwards 😁

@jwildeboer Nice. Just took a look at your protocol. Please add the type of the id, not only the return values. So I expect a package to connect to a server on a standard port and then do nsyncRet := getHash(myUUID).

@themue Protocol is bit exaggerated ATM, so I take it as a compliment ;) Yes, sure. It needs a lot more definitions and technospeak. I just needed to get it out of my brain and into a repo first :)

@themue So if you have some cycles to spare, please feel invited to send pull request, issues, commits :)

@jwildeboer Will do. A good reason to get a Codeberg account too.

@themue I've added a few clarifications and unified the syntax/terminology. Once I start coding, I will see what more is needed (and it will be. a lot ;)

@jwildeboer @themue I looked up nsync on wikipedia... just out of curiosity.

First, nsync no longer exists as a band.. And second, there already was some conflict about the naming after nsync left RCA... they solved this by simply changing the spelling (iirc they added the ' and lost the *;)).

So there should probably ne no problem coming up from that side. ;) IANAL! just AFAICS. ;)

@themue @hackbyte Thx :) If it should be a problem, I’ll rename it to NuSYNC ;)

@jwildeboer @hackbyte Do we wonna add multi-language server/clients on your site or shall people create their own libs? I’m interested in creating the #golang ones.

@themue @hackbyte I was thinking of keeping the protocol definition and at least one reference implementation for the three parts I see ATM (adding nsUIDs, retrieving nsUIDs and managing hashes and content) in the repository. Anything beyond that - let people do their thing where and how they like :)

@themue @hackbyte I you have a codeberg account, I can happily add you as collaborator to the repo.

Sign in to participate in the conversation

Mastodon instance for people with Wildeboer as their last name