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.
>
To clarify, I don't view all chains of the DID method registry in a
negative light. Indeed, certain methods do not involve a chain at all.
However, I do maintain that there are some crypto chains that behave
unethically, thereby casting a shadow on the whole endeavor. I played a
role in initiating the DID work by translating cryptographic primitives to
linked data for the first time, so its current state is slightly
underwhelming.  But if you add one DID method, it's like adding them all.
Because it's not one spec it's more like 170, as listed in the DID method
registry.

It's noteworthy that various chains listed in the DID method registry have
been classified as illegal by the U.S. Government. The lack of concern
shown by the DID group over this fact, coupled with their refusal to
reluctance such chains, is IMHO concerning.

In my opinion, this clip beneath succinctly captures the type of legal and
ethical boundaries being overstepped, too often:
https://twitter.com/VandelayBTC/status/1493310858147123201

Legal safeguards exist to shield end-users from the inherent conflicts of
interest that arise from undisclosed and unregulated token sales to an
uninformed public. A similar level of awareness and protection is necessary
within our standards as well.

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
>