I am curious as to whether ActivityPub could support something like did:web or maybe did:webfinger for discovering the Actor object/document
-
I am curious as to whether ActivityPub could support something like did:web or maybe did:webfinger for discovering the Actor object/document
Feels like that should be possible, but last I looked the did specs were indecipherable to me.
Though, I do wonder if there's a need for an ActivityPub actor to be able to have multiple inboxes/outboxes?
Probably something @pfrazee.com might have thoughts on, but it could bring better interop between AP and ATProto
-
erincandescent@akko.erincandescent.netreplied to thisismissem@hachyderm.io last edited by
@thisismissem I don’t remember the specifics of DID resolution but i don’t see why they couldn’t be used in the same way as Webfinger
But there isn’t a good/meaningfully useful did: subtype so…
-
thisismissem@hachyderm.ioreplied to erincandescent@akko.erincandescent.net last edited by
@erincandescent yeah, there definitely seems like some stuff that would need to be specified still, but I'm thinking it could be done, superseding or complementing webfinger.
-
erincandescent@akko.erincandescent.netreplied to thisismissem@hachyderm.io last edited by
@thisismissem What advantage do you get though?
-
thisismissem@hachyderm.ioreplied to erincandescent@akko.erincandescent.net last edited by
@erincandescent perhaps better interoperability with things using did’s? e.g., I see some stuff about using did’s for verifiable credentials and stuff.
It's funny, we've did’s, activitypub actors/webfinger, and webid, all defined by the W3C
-
trwnh@mastodon.socialreplied to thisismissem@hachyderm.io last edited by
did:web is basically just https: but guaranteed to resolve to a did document
(some) did methods (like did:web) come with the `services` property which can be used with `service` + `relativeRef` param to build relative URLs (which could allow you to e.g. make your activitypub ids have a variable baseURI, useful for migrations or for vhost type situations)
you also can put your keys into the did document instead of in the actor (and specify allowed usage of keys)
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@thisismissem @erincandescent for example having separate keys for separate purposes, your `authentication` key should not be the same as your `assertionMethod` key. if someone steals your `authentication` key they can login as you but they can't make any assertions on your behalf. this is like how github has separate sign-in keys and signed-commit keys
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@thisismissem @erincandescent note that you don't strictly need dids to do this stuff, it's just that did-core provides a convenient standardized framework for defining these things.
it's possible to have an actor uri be both a did document and an actor document and probably also a gateway/endpoint that resolves relative references. there's a fep that tries to do something like this https://w3id.org/fep/e3e9