@mpjgregoire @cogdog there are a couple of thoughts here:
RE: https://mastodon.social/@bagder/116359048796181736
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
@julian@activitypub.space As I understand the migration path, it's like
1. Able to receive RFC 9421 in addition to draft-cavage
2. Able to send RFC 9421 in addition to draft-cavage
3. Send RFC 9421 by default, but be able to fall back to draft-cavage if needed
So by “can't handle” I meant step 1. 🙂 Although the unspoken step 4 is to remove draft-cavage support once everyone else has taken step 1, I'm ultimately also wondering when we'll get there.
@julian@fietkau.social @julian@activitypub.space Honestly, I think it's going to be a while.
I think the term for step 3 is "double knocking", and it's called out in the HTTP Signature report for the Social CG:
@julian ah, right! I meant, many Fediverse servers don't do a good job with caching headers, but you can use some of the data to guess if there have been changes. Caching headers are better though!
@hongminhee awesome! Thanks for the detective work. I'll catch us right up.
@hongminhee so, the good news is that I can use the Fedify CLI to do an authorized fetch for an actor, and the debug output shows that RFC 9421 signatures worked. 🥳 The bad news is that the follow test still doesn't work. 🫤 I'll keep trying and see what I can do.
Cache-Control and Vary
Thanks to everyone who replied! Unfortunately HTTP caching is not our strong suit in the ActivityPub world; HTTP Signature header(s) are a real public cache buster. But you can do at least some good caching per user. tags.pub provides ETag, and sends If-None-Match and If-Modified-Since, but doesn't do Last-Modified well yet.
The problem with Signature: and Signature-Input:
If the server wants to say, "this content is different for different users", you use the Vary header. For OAuth, you'd use Vary: Authorization, say. And the cache knows to separate data for different users. Same OAuth token, you can reuse the cached data.
We include our ID in the Signature (or Signature-Input) header. But we also include a timestamp there, so every single request has a different signature (by design).
@julian hmmm. With a reverse chron collection you can do pretty well with `totalItems` and the first item on the first page.
If there were net items added or deleted, `totalItems` will be different.
If the same number of items were added and deleted, the most recent item will be different.
So you can check synch with a couple of hits.
@aj @mayintoronto @jakebrake @_elena @elena Oh, I'm so glad to hear that!
@rick I think the problem is with the signatures. @hongminhee gave me a bug report and I'm working on it right now. I'll let you know when I have it live and tested. Thanks for your persistence!
I am also, but maybe in a different way.
As someone who helped create ActivityPub and works every day to promote its use, I absolutely believe that everyone should make and use ActivityPub-native software. At SWF, we only do ActivityPub projects.
But if someone chooses to build on ATProto, and to make their software and accounts bridgeable so we can stay connected, that's infinitely better than being cut off entirely.
I mentioned elsewhere that I think supporting the openness of the Atmosphere is important for whatever comes next there. Whether BlueSky thrive or don't survive, the more the ATproto stack is standardized and independent, the better it is for the Fediverse.