Migration <> Key-based Interop (formerly a propos of the weekly issue triage update)

I'm sorry, I love you Melvin, and I love Nostr, but "unscrupulous DID 
methods" is scare-mongering and guilt-by-association. DID methods can't 
have scruples, they are URI schemes for future-proofing and locking-open 
PKI publication mechanisms. In the best of cases, they make key material 
for a given account recoverable long after the heat-death of all 
companies and co-ops involved.  Blanket aspersions on anything that 
touches a blockchain or anything that touches a cryptocurrency are 
unhelpful and making them toes the line of W3C's code of conduct, 
particularly since there are people subscribed to this list who have 
paid their rent with cryptocurrencies at some point in their lives and 
such aspersions indirectly insult them and the time they volunteer to 
this community.

Decorum aside, I have spent the last 5 years wrangling with the 
variously-scrupulous business models around DIDs and VCs, and I find 
very little ground for such suspicion about DIDs. My experience is that 
most DID methods are over-engineered or inflexible not for nefarious 
Venture-Capital/platform-economics reasons, but simply due to the hubris 
of engineers who underestimate the complexity of identity systems that 
represent humans, which, being social systems, are unpredictable and 
evolve rapidly.  DID methods coupled tightly to the identity system of 
any platform involving human actors (be it a cryptocurrency or a closed 
platform or an open platform) rarely go far, because they are meant to 
be artefacts of translation and migration, NOT 1:1 mappings of 
"accounts" in any system that gives humans accounts. I personally find 
it unrealistic to bolt one uniform DID method or PKI system onto the 
entirety of today's disjointed Fediverse with its very heterogenous 
account models and flows, much less cut and paste Nostr's or Bluesky's 
or Farcaster's or Matrix's or Secure Scuttlebutt's identity system onto 
that wide diversity of implementations and form-factors. The diversity 
of instance/client models is just too high, and the reasons people use 
those services too heterogeneous.

I support FEP-521a + FEP-c390, because together they enable the maximum 
number of key-based translation and migration approaches. FEP-521a 
allows a one-way link *to* multiple keys and keytypes controlled by an 
AP actor's "account" *from* a DPKI system that 
controls/rotates/publishes keys. It defines a minimally opinionated 
interface that's DID-Doc friendly without even requiring full 
conformance with DIDs in general or any one DID method--it's a helpful 
superset of "DIDLand".  FEP-c390 allows bidirectional linkages, such 
that DID-expressable keys can sign objects in the way that any DID can 
sign any object in the sprawling graphs of Linked-Data Land. Crucially, 
FEP-521a salvages implementations' past work on the `publicKey` property 
and enables interop with the maximum diversity of external systems, 
including ones that require multiple keys or specific key types.  (Full 
disclosure, I'm also a big fan of multikey and am trying to get that 
spec hardened into an IETF spec+IANA registry, which should de-risk and 
future-proof this commitment to multikey a tiny bit).

My main argument for these two very thin-layer FEPs is that they don't 
try to retrofit any one key-based actor model onto the implementations 
that support them or impose much on their own usage of those keys-- they 
just present a minimally-opinionated interop interface.  They make 
today's Masto and Masto-like identity models a "verificationMethod" and 
show those implementations what a LD-style signature looks like that 
composes well with LD-based interop of the AP data model.  They leave 
the implementations free to get fancy or not with authentication, 
custodial or non-custodial keys, multi-device models, delegation, 
authorization, etc.  It is an incremental move towards key-based interop 
and migrations, and if enough major implementations supported some 
version of FEP-521a and FEP-c390, further FEPs could define bridges to 
Nostr, Bluesky, Farcaster, Matrix and/or SSB based on more opinionated 
profiles of them (i.e., FEP-521a + key of type XX + any DID methods with 
Y1 and Y2 properties = bidirectional account bridge to ZZ). At first 
glance this sounds piecemeal and messy but it's also more composable, 
and in my experience composability is key to building bridges.  Even if 
it leaves the door open to DID methods or social networks that some 
might find distasteful. Decentralization is messy!

I would also add that Bluesky, whatever else you can say about them, 
have been very circumspect about locking their development into one 
model of portability and translation, which is why they are using a DID 
method called "DID placeholder." Some of us from the DID world met with 
some bsky engineers to ask what they were looking for in a DID method, 
and they stumped us-- none of today's DID methods meet all their 
requirements, which is why they are gracefully punting.  This strikes me 
as a commendably incrementalist approach to key-based identity, which 
keeps open as many doors as possible until there are clear reasons to 
start closing any.

Sorry to rant,
__bumblefudge


On 7/14/2023 6:58 PM, Melvin Carvalho wrote:
>
>
> pá 14. 7. 2023 v 18:07 odesílatel Bumblefudge von CASA 
> <virtualofficehours@gmail.com> napsal:
>
>     Say what you will about a per-account key system (such as
>     prototyped in
>     FEP-521a), it would certainly enable some elegant solutions to this
>     problem, such as allowing users to export a key or delegate
>     authority to
>     some kind of external authenticator, which could be used in an
>     unknown
>     future to trigger an custodial export when a server spins down and
>     dumps
>     all its data in a massgrave (with fancy authorization for recovery).
>     The simpler you make it for accountholders to prove "rightful"
>     control
>     of a backup, the easier it is for backups to execute migrations on
>     behalf of servers that went down, right?
>
>     In any case, definitely support documenting mastodon's status quo,
>     because a LOT of financially fragile servers are running it, and
>     their
>     moderation costs and compliance costs might go through the roof in
>     the
>     coming months, so it seems an urgent community service beyond more
>     long-term plans for cool solutions to the underlying problem.
>
>
> I love the potential of per account keys, although successful 
> implementation lies in the specifics.
>
> One concern I have is the potential misuse of this feature, 
> particularly in cases where it could inadvertently lead users towards 
> projects engaged in public token sales, which could potentially 
> involve legal issues. This is something I've observed with web 
> monetization and many DID methods.
>
> Nostr has implemented a per-user key system effectively within a 
> social framework. Their model allows for seamless migration with 
> minimal overhead. I believe a similar approach could be beneficial if 
> integrated with AP.
>
> Migration could be significantly facilitated by combining a 
> well-documented Mastodon specification with the option to add keys, 
> but it comes with huge risks of ushering in unscrupulous DID methods 
> or webmonetization, whose aim is to turn the fediverse user base into 
> the product.
>
>
>     On 7/13/2023 12:41 AM, Evan Prodromou wrote:
>     > Yes, great idea.
>     >
>     > I think the current plan is to document the behaviour of
>     Mastodon in
>     > this area, as step one, with a Note or FEP.
>     >
>     > We'd probably need to then discuss problems with the Mastodon
>     > technique, namely:
>     >
>     > 1. If the origin server goes offline, there's no way to move the
>     account.
>     > 2. Similarly if the account is defederated.
>     > 3. All activities and content stay at the origin server, which
>     keeps
>     > their URLs active, but doesn't help if the server goes down.
>     >
>     > The topology of the fediverse is such that most users have gratis
>     > accounts on small, unstable, volunteer-run servers,
>     > donation-supported. That has made this migration process very
>     important.
>     >
>     > I'm personally a fan of using a domain as your identity, and moving
>     > from service provider to service provider as needed, transparent to
>     > your social connections. But that's not the fediverse we've got
>     right now.
>
>
-- 
------------------------------------------------------------------------
@bumblefudge in a few places, including https://chainagnostic.org