@mpjgregoire @cogdog there are a couple of thoughts here:
@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.
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?
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).
@steve @trwnh @hongminhee ha! That was the notice that got me to become a maintainer. But I don't have the admin rights to change it!
@jasnell can you give admin rights on the activitystrea.ms repo so I can change the message and also push automatically?
@evan James archived the repo today, assumably in response to this question. I'm going to keep working from my personal fork, and I'll use that to push to npm. I think I can update the info in package.json on the topic, too. A change that's been waiting too long.
Since they have $100M in the bank, 3 is probably a way off. AFACT, they are currently doing both 1 and 2 in parallel; if you look at their protocol engineers, I do believe they are really all in on 1, but much of the rest of the company is taking every opportunity to act in a decentralized manner and going in the opposite direction.
@ricci @hamishcampbell @_elena well, they had $100M when they raised money last year.
Crypto funds love to rollover crypto assets. So maybe some of it was in crypto, like Bitcoin, which has since dropped 25% against USD.
And they've been operating a tech startup with 20-30 staff and dozens of contractors, plus hosting costs which are somewhere in the $20-50M/year range, I'd bet.
If I had to guess on runway for BlueSky today, I'd say 12-24 months.
@julian @evan @njvack @dgfitch @skinnylatte @tankgrrl @Viss @ai6yr @mayintoronto
Wow that is just brilliant. I love how the SFO *airport museum* staff just went off and figured out how to track items (and planes visiting the airport!) and everything in a low-cost scalable way that totally plugs into the Fediverse. Neat! :fediverse:
@mastodonmigration @hamishcampbell @_elena I won't argue with this. Having two incompatible stacks hurts the entire ecosystem. When developers and decisionmakers see that, it makes them want to sit back and wait to see what comes out on top.
I think our best mitigation for that right now is reassurance that investing time, energy and money into ActivityPub will not be a waste.
💯 Slow and steady wins the race. It is just frustrating that people are so easily distracted by bright shiny objects.
This all brings in a firehose, which can be a lot of data to handle, especially if you're only interested in a few topics.
Fedibuzz has solved this really nicely, by having one relay per hashtag. So an admin can add a few hashtag relays for topics of interest to their users.