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

so 15. 7. 2023 v 13:39 odesílatel Bumblefudge von CASA <
virtualofficehours@gmail.com> napsal:

> 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
>

In my respectful opinion, I believe it is critical to maintain the
integrity of the fediverse by firmly discouraging those who may be
interested in leveraging this platform for the sale of pre-printed tokens.
There is evidence that such individuals or groups exist within our
community.

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
>