With respect to #ActivityPub
-
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.
-
Jenniferplusplusreplied to Jenniferplusplus last edited by
@benpate
Anyway, I'm strongly in favor of messages with a defined schema. Just be aware it's not doable in a backward compatible way.And I'm strongly in favor of a defined method for *3rd parties* to resolve inconsistencies. Some other server can ignore my reply restrictions, and there's no way to stop them. I want 3rd parties to know that was out-of-spec and should be discarded.
-
This is a great suggestion, and discussion around it. We're far from working through the specifics, but I've made a note in my original document that we should (suggest?) the use of standard HTTP caching and rate limiting headers. We can work out the details when we get there, and put together a protocol that makes sense.
@lily @puppygirlhornypost2 @jenniferplusplus @hrefna @sebinthestars
-
Ben Pate 🤘🏻replied to kopper [according to whom?] :colon_three: last edited by
This is a good point, and I don't have everything worked out, here. HTTP signatures are consistently the #1 pain point, so I'm looking for some kind of solution.
In theory, I'd like DMs to be E2E encrypted, so posting them anywhere in plaintext already seems like an anti-pattern. But, that would be an even bigger hurdle to jump in a project that's probably too ambitious, already.
@kopper @hrefna @jenniferplusplus @sebinthestars @puppygirlhornypost2 @lily
-
The primary question, now, is: "Do we think we should have a discussion about HTTP signatures, and various ways to replace them?"
I'm not committed to simply throwing them away with no replacement, but, by including this in the discussion it seems like the answer to the primary question is "yes". We may not have good solutions, and we may not even have a consensus, but it sounds like we should have a discussion.
@hrefna @jenniferplusplus @kopper @sebinthestars @puppygirlhornypost2 @lily
