Hey folks, we at Distributed Press have been working on making a bridge between peer to peer or “dweb” protocols and ActivityPub implementations over the past year and wanted to solidify our approach so that others can interoperate.
Here’s is an initial draft explaining our work. We also have some live sites and implementations linked from there for those curious to try them out.
For anyone attending DWeb Camp in August, my colleagues will be there to chat about it in person if you’re curious.
This issue supersedes the previous one so that I may edit the OP post.
I’m curious what @SoniEx2 would have to say about this proposal, since this is maybe the lowest-level at which “multihoming” could be architected and might be a better fit for their model (as I understood it) than the HTTPS-based “independent actor” identity approach.
(I also wonder, @codenamedmitri , what it would look like for “independent actors” hosted over HTTPS to accomodate this form of multihoming-- perhaps it’s easier to detach the two problems and let multihoming be the killer feature that existing implementations don’t have to implement if they just implement the smaller lift of externally-hosted actors )
This looks more or less how we’d do it. However, we’d like to see an example of accounts existing across domains, not just across protocols, and including the possibility of separate inboxes.
i’m super into it, straightforward and totally backwards compatible.
couple stray ideas:
thoughts about adding some method field to it? the scheme of the href URI in the ipns:// case indicates how to resolve it, but one might also imaging doing foolish things like putting the document in DNS, or hosting an identity as an npm package (i’m not saying these are good or bad things to do, just that they might have their occasion). one might also want to have a method in the case there is some non-scheme special mode of accessing the document. For the sake of not polluting the FEP with another schema, this could be a linked-data style “add a URI here that is up to the recipient to coordinate understanding out of band.” One could add additional external vocabularies/etc. to the context to give it stricter meaning. That might also help with the potential for needing, e.g. a specific version of a client to access an identity (hopefully not, but it could happen)
on the semantics of the link, is it intended as “this other actor is an equivalent one to this one” or “this is another actor that should be considered the same but might not be equivalent?” like i am very into the idea of having an array of alts that i claim, but for the sake of implementation, would i be expected to keep a full mirror of all the stuff on one on every alt? or would the expectation be that they can diverge with no attempt at being synonymous.
edit: coming to this thread after seeing FEP-1042 which looks like it was added 5 days ago, but i see the posts in this thread 5 months ago? sorry if i’m in the wrong place
Will this work with the concept of nomadic identity, where your identity can be located in more than one place at the same time (preferably as synced clones of one another)?
Originally conceived in Zot protocol and available on Hubzilla and (streams), it has recently been ported over to ActivityPub by (streams) and Mitra. Currently implemented on servers, there is no reason the same technology couldn’t be deployed using a client or peer-to-peer model.
The simplified explanation is that Zot uses a key pair and a hash to identify each user, while the ActivityPub version uses a DID. This is what identifies a unique user. Since it is not tied to a domain, it can be easily be migrated or used from more than one location.
Regardless, of the method used, the @username@example.com is just used for display (and perhaps for routing) and is subject to change. In the case of nomadic identity using servers, the domain name is their primary server, but for a peer-to-peer fediverse identity, this could indicate the primary gateway the user is currently using. If the primary server or primary gateway changes, then the @username@example.com changes to reflect that.
If we were able to give people the flexibility of storing their identity on their device or on a server, or on both at the same time, it would allow for migration, backups, and cloning of identities.
FEP-ef61 DID-based identity is different from what was proposed here in that it is transport-agnostic. I think it can work with IPNS, but then IPNS node should be used as a gateway (similar to a web gateway):
)