Mike Macgirvin ⚡ - mike@z.macgirvin.com

Fri, 08 Feb 2019 01:55:37 -0800

The next phase after location independent identity is location independent content. On top of ActivityStreams - which is about location independent as London. And with every other fediverse developer insisting that I'll fail because they can do it so much better (even though none of them have ever tried to do anything comparable).

What could possibly go wrong?

show all 18 comments

Mike Macgirvin ⚡

Thu, 21 Feb 2019 16:13:24 -0800

In traditional messaging you send a (complete) message to a recipient. In the modern era (ActivityStreams, on which Zot6 and ActivityPub are based) you often send incomplete messages, with links that point to any missing objects. These are fetched on delivery to assemble the complete message. This is fine for ActivityPub, but when you include nomadic identity in the picture, the link could point to a dead server and won't be valid over time - unless that server is always there.

So we're using a custom URI scheme that looks like:

x-zot:xxxxx/yyyyy

xxxxx is the nomadic identity of the owner and yyyyy is the nomadic identity of the document or object. A particular xxxxx/yyyyy pair is guaranteed to be unique in the entire network (as is the owner identity xxxxx).

So if you receive a message with this identifier you can lookup the owner and find out where to fetch the data from based on their current location information. And if that fetch fails, you can try the next one. They may have multiple locations and one or more might be down at any time. If you don't know the owner, you can ask the person who sent you the object because they will know where the identity is stored. And if all of these fail, you can ask a directory server for the latest location information. The end result is that in 99.999% of cases you can retrieve the information, even if the channel's main server is dead.

If you've ever messed with P2P apps, this basically represents a distributed hash table. Most of the time your server will already have the available locations stored and no network lookup is required. Network lookups in the vast majority of cases are performant to O(1) lookups and in rare cases O(2). This compares quite favorably to technologies like bittorent which has O(log(n)) lookups where n is the number of nodes in the network. And we can still provide such a full distributed network search if the directory server didn't return anything useful.

I was deep into this before I found out that Chris Webber (the ActivityPub co-editor) is working on a similar scheme but actually using bittorrent over ActivityPub. The drawback is that he's tied to ActivityPub and we had this same problem with nomadic identity. Unless everybody in the network supports nomadic identity and nomadic content, nobody can. We can do this because we currently provide all the software in the zot6 network. I believe his approach is likely to be doomed because he'll never get every ActivityPub project on the planet to adopt torrent storage. It's interesting; but that's a huge step from something theoretical to actual adoption. We can adopt nomadic content right now.

In fact it's already available.

A.minimus

Thu, 21 Feb 2019 22:03:20 -0800

Fantastic. Thanks for the explanation. Exciting times.

h.ear.t

Fri, 22 Feb 2019 01:33:20 -0800

From another post that I cannot share directly right now:

Hubzilla will be able to access this nomadic content and share it with others. The code to do this is in the current 4.0RC branch and is a core protocol ability. It's doubtful if other network protocols will ever support it as it seems that data resilience and mobility in the face of disaster is about as popular as herpes.