With respect to #ActivityPub
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] I have something that's sort of protocol related. The lack of rate limit headers for activitypub implementations... I know that's not really defined or governed by the protocol... but it's just stupid how we send thousands of http requests at once, and how we only back off when we hit the rate limit. I have talked about this, using rate limit headers would allow for instances to send a steady stream of requests without overloading the remote instance, saving time. We use exponential backoffs which... if the server is rate limiting me for 10 minutes but my jobs failed so now my instance is going to wait 8 hours to send jobs... it's so fucking stupid. i hate it. bothers me so much
-
@benpate @puppygirlhornypost2 @jenniferplusplus @hrefna @sebinthestars yeah now that i think about it the issues with the approach could be mitigated with a cache duration during which it doesn't fetch a new version. although that could become an issue with edits
or there could be an spf-like verification step to make sure the request can only come from the originating server -
kopper [according to whom?] :colon_three:replied to Ben Pate 🤘🏻 last edited by
@benpate @hrefna @jenniferplusplus @sebinthestars @puppygirlhornypost2 @lily
in both object-based signature cases and what you call lookup validation, how do i end up implementing the same access control (theoratically per-actor, practically per-instance) http signature can give me? -
It _can_ be specified by the protocol, however, it's just not. Some other protocols do this and there's no reason so long as we're talking more broadly about HTTP headers generally.
-
Hrefna (DHC)replied to kopper [according to whom?] :colon_three: last edited by
There's no access control inherent HTTP signatures or in how they are generally implemented and using it for that purpose is _very_ hackey.
If we want access controls there are better solutions with things like JWTs.
@benpate @jenniferplusplus @sebinthestars @puppygirlhornypost2 @lily
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] I mean I wish it was standardized. Also, what would be nice is a filtering of certain activities. Not every activity takes the same amount of work (a delete activity vs a create activity for instance, deleting is cheap...). the fact we just sorta throw out a wicked mix of jobs with varying processing times as if they're the same...
-
kopper [according to whom?] :colon_three:replied to Hrefna (DHC) last edited by
@hrefna @jenniferplusplus @benpate @sebinthestars @puppygirlhornypost2 @lily
sure, but currently "dropping http signatures with no proposed alternative" leaves me unable to make sure DMs only reach the instances they're supposed to (well, in a best effort basis, anyway). i'd welcome a better alternative but it needs to exist before http sigs can be disregarded -
Even better we don't specify exponential backoff ^^ Just say "you SHOULD use something like it."
AP is seriously DDoS as a service.
-
Hrefna (DHC)replied to kopper [according to whom?] :colon_three: last edited by
How does this "make sure DMs only reach instances they're supposed to"?
@jenniferplusplus @benpate @sebinthestars @puppygirlhornypost2 @lily
-
@hrefna @kopper @puppygirlhornypost2 @jenniferplusplus @benpate @sebinthestars http signatures are used for authorised fetch by basically all fedi software
-
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] I'd have to check how dms are implemented. I think that if I were to implement them I'd be under the assumption they should directly go into a specific actor's inbox (ignoring shared inboxes entirely) and that nobody should be fetching them. I mean... I guess it could be useful to use authorized fetch to verify that the instance in question was authorized to receive the object (say someone accidentally deleted a dm and they wanted to fetch it again from a remote instance)...
-
@hrefna
The biggest value of http signatures is that they're not forwardable. They also provide some forgery protection. And as long as we're relying on self-asserted credentials, it's no worse of an authn mechanism than anything else. But you're right they convey no authorization, and that's something I wish we had. -
This is correct for how it should work in most cases. In this case _no one_ should be fetching them without stronger access controls than what authorized fetch provides. Including the remote server.
You could conceivably also use a capability URI if you _did_ need to dereference it, and HTTP signatures + "authorized fetch" don't really provide much on top of that. Especially with the way they are (not) standardized
-
Basically I'm not opposed to saying "we need a RBAC/ABAC" and standardizing on JWTs or whatever, but I'm not convinced we're getting anything of value by saying "oh yes and there's authorized fetch + http signatures to build an ersatz RBAC for controlling information flow," especially if the solution is "don't make them publicly exposed in the first place."
-
Oh sure, there are uses for them and I don't object to using the modern standard for it in the slightest, it's just that a lot of those uses can be done on a per-server rather than a per-user basis.
Basically they are good for a handful of things, but my argument is that none of those things can be called access control and few if any of them are great solutions in that space. Especially at the individual level.
-
@benpate
I only have 460 characters, so, briefly:1. requires breaking interoperability. full stop. Sending in strict mode means peers that don't know what strict mode is won't understand the message
2. this is what AP already specifies. But most people don't want SN apps to be mail clients, so real world implementations drop that req.
3. I still don't know what a peer could or should do with that information1/
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
@benpate
4. Sure, I've wanted a spec-defined federated authentication mechanism since forever. It needs to preserve the privacy of private messages.
5. Yes, I've wanted reply controls since forever. This is a socio-mastodon problem, more than a technical/protocol one.
6. see next post
7. This is also the way that AP is already specified. You can already build an AP mailbox server and punt all of the intelligence to the client. -
Jenniferplusplusreplied to Jenniferplusplus last edited by
@benpate
We keep going in circles on these things because no one knows what activitypub *is*, and there's no common understanding of what we want it to be.If it's a public micropublishing framework, then ATProto is a better implementation of that. If it's a distributed graph sync, then zot, and leaf, and ATProto are a better implementation of that.
3/
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
@benpate
The only thing that AP is (or could be) that others aren't is a directed, scoped, messaging system. Optionally, but not necessarily public. Usually, but not necessarily consistent.Personally, I think that's great.
But that means things like moving accounts along with their content will necessarily be imperfect, because that content was created in an entirely different trust context that cannot be made fungible.
-
I created a topic: Wiki: Vision for a Fedi Specification at discuss.coding.social to start developing a vision.
