arcanicanis on Nostr: Sounds like it doesn’t necessarily ease the burden of implementing did:[something] ...
Sounds like it doesn’t necessarily ease the burden of implementing did:[something] for ActivityPub though. Do you consider it a dead end as far as practical utility goes?
Oh, it absolutely could be used today in FEP-ef61, and the laziest implementations could just lean on querying
https://plc.directory/ for every did:plc. A person could just skip all of the above prerequisites, and at minimum [only] be a consumer of that DID method by just grabbing the JSON (or JSON-LD:
https://plc.directory/did:plc:s2m7kbq2unki7rager5aw6sw ), and having blind faith that the directory validated it (except it'd only be a one-way relationship).
I did accomplish this with no dependencies (other than OpenSSL and a BigInt math library) in ~400 lines of code from scratch.
The significant issue is long-term trust in that DID platform, as there's no idea how they'll moderate it, if they'll force incompatible breaking changes, lock it down later on (for submitting did:plc identities, or resolving them), or if it'll be shut down some amount of years from now. But at least there's nothing that mandates the use of their resolver, as I'm sure others could launch their own, maybe.
Published at
2024-03-23 18:56:16Event JSON
{
"id": "9b5cdd5cebec17f069acb969aff7ec9e012a308d5499f3c424dcae7eacbc8eaa",
"pubkey": "0ed7afc8b04a4ef5d52c14fd46c65e452d62ca50a47d6cf5287ed2825a6d26f7",
"created_at": 1711220176,
"kind": 1,
"tags": [
[
"p",
"ae2ef126e5c3a0e7203aa27d230ed120b8f150d6d0f99ea638c5c6c1e4134889",
"wss://relay.mostr.pub"
],
[
"e",
"7cb1526814fdec458c95b7bc1202d2d0fdb88f90c8d01b4e4beca2d1840e0d3d",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://were.social/objects/669c1495-387b-41b8-89cc-bb2a4f32f6af",
"activitypub"
]
],
"content": "\n\nSounds like it doesn’t necessarily ease the burden of implementing did:[something] for ActivityPub though. Do you consider it a dead end as far as practical utility goes?\n\nOh, it absolutely could be used today in FEP-ef61, and the laziest implementations could just lean on querying https://plc.directory/ for every did:plc. A person could just skip all of the above prerequisites, and at minimum [only] be a consumer of that DID method by just grabbing the JSON (or JSON-LD: https://plc.directory/did:plc:s2m7kbq2unki7rager5aw6sw ), and having blind faith that the directory validated it (except it'd only be a one-way relationship).\n\nI did accomplish this with no dependencies (other than OpenSSL and a BigInt math library) in ~400 lines of code from scratch.\n\nThe significant issue is long-term trust in that DID platform, as there's no idea how they'll moderate it, if they'll force incompatible breaking changes, lock it down later on (for submitting did:plc identities, or resolving them), or if it'll be shut down some amount of years from now. But at least there's nothing that mandates the use of their resolver, as I'm sure others could launch their own, maybe.",
"sig": "c449f143e3f365ad7ddf2efd76c09f33194d62ee80ad791260ab47cca7dc9a2d978e362bf84c0fac769e12fa4fbd5d3c95c9d6b3adeb66ef98d8ccc0b7da0d38"
}
