Goofed Home

@evan

> Rate limits are a common part of APIs.

Yes, of API *implementations*, and they may become part of the public interface of these implementation. Whether they should be part of an open standard protocol specification is a different matter imho. Perhaps in a separate implementation guide, suggesting recommended practices.

Or perhaps there may be some way to formulate a generic mechanism in the protocol specification that makes rate limits an extension point, without pinning to a particular method, esp. if it is only a de facto standard.

(Other example. The fediverse is still pinned to an expired draft of HTTP signatures.)

OTOH if the goal of the task force is to mostly just provide implementation guidance, and maybe a reference impl, then I guess examples of rate limiting may be provided.

@julian

@smallcircles @julian the point of the API task force is to make using the API across servers possible. That's why we're doing the OAuth work. I think rate limiting is part of the basic profile; it's one of the things you need to support to use the API across different servers.

@julian There are 3 main clusters.

They're linked here for the ActivityPub API task force, but they also apply for the federation protocol:

https://github.com/swicg/activitypub-api/issues/4#issuecomment-4083573914

It's been a fun weekend building a new working fediverse applikation.

The tech stack so far..

Backend: Go — fast, simple, great concurrency. No magic, just code.

Frontend: SvelteKit — feels like writing HTML that actually works. SSR out of the box.

Database: PostgreSQL — boring in the best possible way.

Queue: Asynq + Redis — async ActivityPub delivery with retry logic. Workers run separately from the API.

Federation: ActivityPub — HTTP signatures, shared inbox, fan-out delivery for groups and followers.

Infra: Docker Compose — one file per instance, easy to spin up new nodes.

Everything self-hostable. No cloud dependencies. No vendor lock-in.

Still early days — but the foundation feels solid.

And yes - A lot of help fra Claude code. I decided to go all in an use big tech to fight big tech.

#Fedibook #Fediverse #ActivityPub #Go #Golang #SvelteKit #OpenSource #IndieWeb

@sindum Go is the fucking bomb. ❤️

@smallcircles @julian I disagree!

Rate limits are a common part of APIs. For apps to work across servers, the servers need to provide about the same interface.

Using standard rate-limiting headers lets client apps detect what rate limits they will be held to. It reduces the uncertainty.

Fortunately, there is a well known de facto standard and an even better IETF standard coming up. We should point them out.

You know, it’s entirely possible to use ATProto without touching anything owned by Bluesky proper

Pretending that Bluesky is the whole of ATProto is like pretending the whole of the Fediverse is Mastodon

Stop using your ignorance as vindication in your choice of home platform, it’s not ATProto vs ActivityPub

It’s the Social Web vs centralized social media

#SocialMedia #ATProto #SocialWeb #ActivityPub #Fediverse

@julian

I too consider coding, generally, a means to an end.

However, in software development, isn't often the real problem to find out *what precisely* is the end?

Bugs can result from perfectly coded software if you haven't fully considered that what you really, *really* want is zig a zig ah.

@julian that's the way to do reverse chron that messes with caches!

Instead, number your pages from oldest to newest. So page 1 was the first page created. After PAGE_SIZE items have been added, create page 2, make it the `first` page, and now page 1 never changes (unless one of its items gets `Remove`d). All your volatility is in the most recent page, and older pages rarely change.

You can also use UUIDs or other IDs for pages.

@julian the downside is that your `first` page is rarely full. You can get around this by having the `first` page be up to 2 * PAGE_SIZE in length, and shifting PAGE_SIZE items to a new page when the `first` page hits its max.

@macgirvin like, only the most recent page should be volatile. Except for deletions, older pages should not change.

@julian Thanks!

Groups use the FEP-1b12 pattern — Group actors, Follow to join, Create to post, Announce to fan-out — but with one current limitation: group federation is Fedibook-to-Fedibook only for now. Non-Fedibook
instances get a Reject on Follow.

It's a pragmatic shortcut to get something working for now. Full cross-platform group support (Mastodon, Lemmy, etc.) is the goal if it proves feasible.

I mean, I just did every search query as an actor.. and this isn’t much different.

Every *potential* number is ready to go, and just gets a db entry (and actual behavior) once someone interacts with it.

@julian @smallcircles