NodeBB-ActivityPub Bridge Test Instance

kopper@not-brain.d.on-t.work

@smallcircles @hazelnoot @cwebber I'm worried that capabilities in their entirety are an extremely dramatic break from current fedi, which makes it pretty much impossible to gain any adoption without a complete backwards-incompatible break that somehow all software are onboard with.

These tokens are a bit easier to implement which I would imagine would help adoption, but I'm still doubtful it will happen as it would also be a (smaller) backwards compatibility break.

For comparison, our Mastodon overlords seem to be doubling down on HTTP signatures though: github.com/mastodon/mastodon/pull/34814

kopper@not-brain.d.on-t.work

@hazelnoot yeah but won't you think of the poor international standards organization W3C

kopper@not-brain.d.on-t.work

@hazelnoot oh and

- Out-of-band protocol - communication can't happen over ActivityPub / ActivityStreams because this is a prerequisite to authenticate any request. (but again, we already require WebFinger and some software requires NodeInfo for full support.)

throw an @context to the payloads and and suddenly it's not out-of-band. you could go as far as to make it an activity sent to a shared inbox but now implementation becomes a bit more complex as you have to parse the activity first to see if you should validate signatures or not

kopper@not-brain.d.on-t.work

@hazelnoot

i'd support this but it's never gonna happen so whatever

- Breaks the actor model - instances are required as a first-class concept. (but really, the actor model is basically dead already. you can't even federate reliably without a WebFinger server, at minimum.)

per-actor bearer tokens taken from an endpoint in as:endpoints. use the same instance actor concept as you do with http signatures for bootstrapping (also webfinger doesn't matter for the actor model in practice)

NodeBB-ActivityPub Bridge Test Instance

kopper@not-brain.d.on-t.work

Posts