- From: Bumblefudge von CASA <virtualofficehours@gmail.com>
- Date: Sat, 15 Jul 2023 19:42:55 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Evan Prodromou <evan@prodromou.name>, public-swicg@w3.org
- Message-ID: <87b233c7-c14e-ccea-3a8d-10c9c5d442b4@gmail.com>
To be blunt, the opinion of Twitter user "VandelayBTC" or Michael Saylor
(who holds $4.6billion worth of BTC) on as-yet-undecided matters of SEC
enforcement and US case law are about as relevant to our cryptographic
choices here as Google's human rights record in China would be in the
question of whether to implement Activity Pub in golang, or moxie's
early State Department funding in the question of whether to bridge to
the Signal Protocol. You are doubling down on fear-mongering and
trotting out your personal political beliefs instead of apologizing for
slandering the objectivity and ethics of your colleagues. Off-topic and
disrespectful.
But while we're on this topic, let me respond to "various chains listed
in the DID method registry," which is a factual error that actually
bears on the issues at hand. The DID method registry lists export data
models, some of which take advantage of cryptographic primitives and
data models used in blockchain applications. That's it, that's the
entirety of their relationship to cryptocurrency. Those data models are
simply neutral technical documents, like IETF RFCs, multikey entries in
the multiformats codec table, or the machine-readable LD signature
suites you contributed to. No DID method I've yet seen is in any way
bound to one chain or one token (whether that token be a security, a
commodity, both, or neither) so all of this still smacks of ad hominem,
guilt-by-association, and overreaching, paranoid appeals to quo vadis.
DID Methods work across entire "virtual machines" (did:eth), "runtimes"
(polkadot) and families of chains (DID:BTC). What makes a given token a
security, a commodity, or both is the typically capital-intensive
process of fundraising to launch a specific chain produced by nodes
(i.e. "instances") running a given runtime (i.e. "codebase"), not the
codebase of the runtime that creates the chain. This maps neatly to
AP's instance/implementation distinction-- an instance can be illegal
once deployed, but the implementation it instantiates is just code
(which will hopefully remain free speech as a matter of settled US case
law, Tornado Cash notwithstanding). This is why the price, legal status,
and management of Ethereum (the token) have no particular legal or
ethical bearing on the European Commission using IBM middleware ("Besu")
to spin up a permissioned EVM ledger (i.e. unrelated instance of the
Ethereum codebase) to experiment with payment rails and to anchor DIDs
in its R&D work on decentralized identities (did:ebsi). The very real
possibility of Eth (the token) being declared a security and EVM
research having been partly paid for by donations of "ill-gotten gains"
on the part of ConsenSys or other early fundraising participants doesn't
seem to have poisoned the fruit of the EVM codebase in the opinion of
the European Commission, as EVM-based DID methods benefit the most
mercenary and criminal holders of Eth in no particular way.
When anyone brings up these topics in the DID WG in any direction (pro-,
anti-, etc), the chairs there table the topic as exhausted and I
entirely support them for that; I would also support the chairs doing
the same here. I can't see why the [highly international] DID WG at W3C
should be taking sides in the jurisdictional turf-war between agencies
and branches of the US government, which will takes years to settle and
which has no bearing on cryptographic choices. What's more, I sincerely
wish there were millions of dirty crypto money pouring into the parched
W3C coffers via the DID Working Group because at least then they would
be supporting the W3C mission. Alas, despite all my hobnobbing with the
nefarious cabal of crypto-capitalists, I've yet to see a cent of it for
myself or for W3C. There is no one joining the W3C to get their DID
method into the registry. If anything, the W3C is sadly irrelevant to
way too many crypto projects, who take the web for granted and pay more
attention to IETF if they pay any attention to standards at all. I
highly doubt what this CG does will move that needle in any direction,
or have any bearing on US case law or the relative legitimacy of various
global payment rails.
Thanks,
__juan
On 7/15/2023 3:15 PM, Melvin Carvalho wrote:
>
>
> 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
> <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
>
--
------------------------------------------------------------------------
@bumblefudge in a few places, including https://chainagnostic.org
Received on Saturday, 15 July 2023 17:43:07 UTC