RE: https://mastodon.social/@HolosSocial/116286098619535273
The next step with #HolosSocial will be to let you use your root domain as your identity while still using a subdomain for the relay.
Yes, #Holos is kind of like #nostr but with #ActivityPub. The main difference: your data lives on your device, not on a server, and relays remain completely dumb.
New post: Can we have a more “social” media?
https://profpatsch.de/essays/a-more-social-media
On advertising, the Fediverse, and what a more human social web could look like.
Special mentions: @smallcircles, @phnt, @happy-programming
@Profpatsch You need to create a new signature because the request target is changing. It is a part of a signature base, so the initial signature becomes invalid when the client follows a redirect.
@Profpatsch @liaizon The guide recommends limiting the response size, to prevent DoS.
I also found this in your SECURITY.md:
@julian There is federation between fedibook instances usingActivityPub. But I cant see how groups will match i.e. Mastodon.
@julian @Profpatsch oh, yeah, definitely. It's really our only way to authenticate requests right now.
Sorry, but requiring requests to public activitypub objects to be signed is completely whack, merveilles.town
Sorry, but requiring requests to public activitypub objects to be signed is completely whack, merveilles.town
Great, thanks.
@smallcircles @julian I think we might have different ideas about what the ActivityPub API task force is for.
To me, it's about making it possible for clients to use different servers, and different implementations of the API. That's going to include the social API defined in the ActivityPub standard, but it will also encompass things like rate limits, authentication, caching, CORS, and so on.
How that all gets documented will probably be in one or more community group reports.
The extent to which the default profile becomes a 'straightjacket' impact scope, applicability, and usability. I guess its alright as long as there's sufficient flexibility and extensibility taken into account. Guess the "sufficient" does the heavy lifting here.
@smallcircles @julian I think that's always a tension in standards! How do you make it explicit enough that developers can build interoperable software, but extensible enough that they can try new things?
I think one pattern that works well is some base-level standards assumed, and easy ways for extensions to be discoverable and negotiable. If your preferred extension isn't available from the software on the other side of the line, you fall back to the base-level standard.
So, if the rate limit is 300 requests every 5 minutes, and you've already used 143 requests, you might see headers like this:
X-RateLimit-Remaining: 157
X-RateLimit-Reset: 2026-03-22T22:10:00Z
@julian Unfortunately, there are a ton of conflicting variations on this pattern. Some APIs use a Unix timestamp for the reset datetime (!), others use HTTP header values. Mastodon uses an ISO 8601 datetime.
The X-RateLimit-* headers also don't work well if there are multiple quota policies. That can happen if there are particular types of requests that are under a stricter quota than others. There are some variants that APIs use, but they're specific to the platform.
@julian The big advance is the new rate limit headers RFC draft:
https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers
It supports having multiple policies. It's very clean and elegant. Unfortunately, it's still in draft stage. It's probably good to be ready for future changes if you're going to implement this.