With respect to #ActivityPub
-
@hrefna we would be very happy to join such a working group
-
@hrefna we'd like to propose just making a coalition of the willing without any overarching organization, and then having meetings and longform discussions in the way that a standards body does
-
@jenniferplusplus @hrefna Yes to this.
If we *have* to break compatibility, fine, let’s go. But hopefully we can provided a smooth migration path so we’re not rebuilding the whole network from scratch.
The existing AP network (flaws and all) is incredibly valuable -- especially for microscopic projects like mine because it solves the “empty party” problem. If I can connect into an existing network, my app is instantly more valuable.
-
smallcircles (Humanity Now 🕊)replied to Irenes (many) last edited by
Just FYI. Elsewhere on the thread I mentioned that I can facilitate such working group, under umbrella of Social Coding movement, but otherwise retaining full independence to set own course.
smallcircles (Humanity Now 🕊) (@[email protected])
@[email protected] @[email protected] @[email protected] @[email protected] @[email protected] @[email protected] Many points have been brought up in the course of the year and discussed in a variety of different contexts. Trouble is that all of that is now fragmented and dispersed. Ideally we should exchange ideas and insights in a more central location. SocialHub may be too AP-themed for this. I can offer forum space at https://discuss.coding.social and a dev portal at https://fedi.foundation and also Hedgedoc, Codeberg org, Matrix space.
social.coop (social.coop)
Even if only to discuss things upfront to explore the opportunities, it can be very useful to use the forum and maybe other tools available.
-
Hey #Fedidevs -- I've tried to collect the areas where we could improve #ActivityPub and #Fediverse development, including as many points from this thread as I could find. Take a look and tell me how close I am to the mark?
This is me begging for feedback, so don't be shy, but do be kind
@puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
-
I’ve listed seven core topics:
1. Strict mode
2. Rich Interactions in the Inbox
3. ActivityPub Intents
4. HTTP signatures
5. Reply Collections
6. Account Portability
7. Client APII think we could make mostly-backward-compatible changes in these area, and go a long way towards turning the Fediverse into a single, cohesive ecosystem.
@puppygirlhornypost2 @sebinthestars @hrefna @jenniferplusplus @lily
-
@benpate @puppygirlhornypost2 @jenniferplusplus @hrefna @sebinthestars i think you summarised a lot of the big pain points of activitypub pretty well, but i do want to mention that i don't think lookup validation is a good replacement for http signatures, because if we were to solely rely on it as a verification method, it could be abused by malicious instances to make the network ddos a certain instance (or any website for that matter, but that is already happening and doesn't seem to have a lot of impact on static sites) which could be bad for smaller instances running on low-spec hardware
other than a couple typos here and there i think your summary is pretty good overall though -
@lily @puppygirlhornypost2 @jenniferplusplus @hrefna @sebinthestars
Yeah, I’ve gone back and forth on “lookup validation” and I’m happy to be corrected.
It seems to me that it doesn’t open up any additional attack vectors that don’t already exist, but it does drastically reduce the overhead required to send/receive messages.
Low-spec servers may need to improve their caching tools, but I think it’s probably a net win for efficiency.
(And sorry for the typos)
-
@[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.
