Ghost has a (pretty funny) update on their #ActivityPub development.

Johannes Ernst

Building ActivityPub: Day 1

Hello and welcome back to a weekly existential crisis about desperately trying to live up to promised potential. Just kidding! This is a newsletter about ActivityPub. Firstly, thanks for all your comments on last week's newsletter — we did not expect to get so many, and it's amazing to hear your

Building ActivityPub (activitypub.ghost.org)

julian

@[email protected] personally, I'm still waiting for someone to call me out on having actors whose outboxes resolve to an empty collection

ducks

John Spurlock

@julian @J12t

Luxurious! My actors have outbox urls that 404 : ))))))

Johannes Ernst

@julian what’s your reasoning there?

julian

@[email protected] no legitimate reason, we just don't use it, and basic federation doesn't break when it's not implemented, so it's just very low down on our to-do list!

John Spurlock

@J12t @julian

in my case, I found that Threads requires an outbox url in the system actor used to sign fetches.

The outbox url can 404 (doesn't even appear to be called), it just needs to be present : ))))

Johannes Ernst

@julian I've always thought that what you get via push delivery and what you see in the outbox should be 100% consistent, because then if you don't get a pushed update -- e.g. because of a temporary failure -- you can go back and fetch what you missed. But certainly AP doesn't require or even suggest that behavior.

julian

@[email protected] Yes, that's certainly one use-case for the outbox... to "catch up" on things you missed, on a per-user basis.

But as far as I am concerned they're separate APIs that pull from a common data source.

For example, reading the ActivityPub spec, one could draw the conclusion that the outbox is an ordered list of activities, likely read as-is from the database.. but that's not strictly defined, so it's possible to dynamically create outbox items on-demand based on user history stored elsewhere.

That would mean less duplication of content (and the syncing that is required), fewer bugs, etc... but the cost is the collection then has to be dynamically constructed.

Johannes Ernst

@julian It's mostly append-only, easy to cache ...

For FediTest, we have come to the conclusion that simple pass/fail isn't going to cut it. We need a more gradual rating, and the current state is 1) fail -- against the spec and likely go cause interop problems 2) soft fail -- against the spec but probably harmless from an interop perspective 3) degrade -- e.g. everything turns into a Note and 4) pass. Not sure this is an exhaustive list ... your empty outbox would get a pass, I think.