[discussion] Self-Sovereign Identity

[makoConstruct]

(If this is more suited to some ActivityPub forum, I can take it there instead. I broach it here because I think standards ultimately need to be steered by implementations, and I think this implementation has great taste, and also, some of the obstacles are UX issues.)

Why I need SSI:

• It's hard to justify using bonfire for contracts, transactions and accounting or anything serious (any system that results in actions being taken in the real world) when instances could either impersonate their members to steal assets or, through negligence or as a result of an accident, go offline, lose their data, and permanently lock people out of their accounts.

• (edit: on reflection, this can be done without SSI, it's just rare that people do, but there isn't really a reason for that) SSI can make the signup process frictionless. The user's browser can generate a key locally and they can sign up and authenticate using that, without having to go through an email registration process (the new account can later be given an email address, or merged into another account that has a recovery email or a recovery key registered). Friction is a huge deal. Any amount of friction makes a lot of legitimate social technologies infeasible. This might matter to bonfire if bonfire starts getting extensions that are so useful that they don't really need the rest of the social network for users to be interested in them, tools like when2meet or piratepad, where social network integration is useful, but not necessary, and where eliminating lowering barriers to participation is crucial.

So, this is important. But from what I understand, this is going to be difficult to do on ActivityPub, it seems like users are always referenced via their instance name? Which in turn answers to the DNS system?

[mayel]

Interesting topic indeed!

There's a few things on the backburner which I'd like to do in that direction:

1. Be able to enter a username with a different domain than one's instance Example: if I (or a friend or family member) have registered the domain name mydomain.com and have signed up to the bonfire instance aroundthefire.net I should be able to identify as @mayel@mydomain.com rather than @mayel@aroundthefire.net To do this, Bonfire could generate an appropriate webfinger JSON file that I'd have to upload to be served alongside my personal website at /.well-known/webfinger so that querying http://mydomain.com/.well-known/webfinger?resource=acct:@mayel@mydomain.com would return something like:

   {
   "aliases": [
       "https://aroundthefire.net/@mayel",
       "https://aroundthefire.net/pub/actors/mayel"
   ],
   "links": [
       {
           "href": "https://aroundthefire.net/@maye",
           "rel": "http://webfinger.net/rel/profile-page",
           "type": "text/html"
       },
       {
           "href": "https://aroundthefire.net/pub/actors/mayel",
           "rel": "self",
           "type": "application/activity+json"
       },
       {
           "rel": "http://ostatus.org/schema/1.0/subscribe",
           "template": "https://aroundthefire.net/authorize_interaction?uri={uri}"
       }
   ],
   "subject": "acct:mayel@mydomain.com"
   }

   We'd have to make sure that instance migration (like Mastodon does) could still work, so that I can move from aroundthefire.net to burnitwithfire.xyz and retain followers while my mayel@mydomain.com username does not change.

2. Explore the possibility of optionally using just a domain, eg. @mydomain.com as a nick rather than requiring a domain + username. This would only work for people who have a personal domain name.

The above are of course just stopgap workarounds for the way the fediverse works today, with it's dependency on the WebFinger standard and DNS based identity. Blockchain people would probably have many other suggestions but I'm not into that stuff...

[mayel]

There was also someone working on a distributed hash table project for the fediverse: https://socialhub.activitypub.rocks/c/software/hash2pub/48 for hashtags that could probably be adapted for something like this. But it seems to not have activity for a while.

[makoConstruct]

I spent some time searching and concepting for a way of doing the full thing, where users are always guaranteed to be able to recover control of their session key listing even if their primary host goes down, and... I think I've just ended up reinventing Holochain.

I'd bet that there simply isn't a way to do SSI with reliable exit without having a general way of reaching consensus about the most recent version of the state of shared computations, which is, you know, a smart contract system. But I believe I can see a concept that does this in a fediversy way that wont require any gas fees.