@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?
@evan Thanks for the response. I think how a given software does double-knocking is up to that software. It is not necessarily true that you have to store the result, but it is ideal. I am much too lazy to refactor a persistent cache and I just double-knock every time. :P
But to start, those libraries need to be able to support both signature implementations as those libraries are already in-use by the majority of software that has not implemented RFC 9421 yet.
@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:
Friends, if you haven't already, it would be a big favour to me if you could enable tags.pub to boost your public tagged posts.
Just follow @_followback . It will follow you back, and when you make a post with a hashtag in it, the server will boost your post from the appropriate hashtag.
If you're interested in any topics, like @nokings , follow that account to get posts with that hashtag from across the Fediverse.
Let me know how it works for you!
@tchambers @joe great idea!
I think it's a really interesting question of how much of the Fediverse needs to be providing data to tags.pub.
I think this might be an interesting network science problem. I'll do some math and let you know!
@evan I read years ago that multi-word tags should be done in CamelCase, for the benefit of screenreaders. So when I take my posts, I'm careful to do so. It appears however that tags.pub lowercases all my tags.
I understand that it shouldn't create separate accounts for tags that vary only by capitalisation, but when creating a new account, why not preserve the capitalisation of the original tag?
@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!