Notices by Beady Belle Fanchannel (profpatsch@mastodon.xyz), page 2

@civodul > A policy that permits the use of AI/LLMs in any capacity or is declared to be vibecoded. Both vibecoding and opening the door for people to vibecode count as a permissive AI policy.

What a big huge dumb pile of bollocks this is

@evan cause most Implementations already treat it as if it was plain JSON with a subset of ActivityPub semantics

@silverpill @hongminhee why do we need this kind of complication? What's wrong with just always expecting an array and simplifying the standard instead?

@evan @mariusor @silverpill @hongminhee I can't wait for us to finally drop jsonld in a living standard

This is a joke, right?

https://app.element.io/ returns 451

#matrix #element

Arnold Schrijver (@smallcircles) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read!

https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow

#activitypub #fediverse #FEPs #fep #fedidev

I'm thinking of replying in a blog post as someone who has spent the last three months actively developing a fediverse application (#flohmarkt).

But the most critical thought: I miss a discussion about reducing implementation complexity as much as possible. The standards leave much "wiggle room" for implementation, which I think is partly to blame for the "whack a mole" nature of support

Things that come to mind:

* Inbox signature validation is very vague
* jsonld is a complex standard that introduces a need for libraries, leads to slowdowns and blows up the implementation surface
* Interaction schemes like quoting requests lead to nontrivial state machines

In general: any MAY in a definition explodes the possible things that can go badly.
Which is why I think we need to use a different approach from how e.g. RFCs are structured

@aral this is stupid and wrong

@silverpill @i That is very cool and I don’t know how I haven’t seen it before; it kinda invalidates part of the nlnet funding ideas that I wanted to apply for :)

The cool thing about the Activitystreams Activity Vocab RFC is that it’s nearly completely useless for any practical implementation purpose …

#activitypub

@i The thing is that it’s really not useful to define super generic terms that are not even pointing to existing implementations, and could have any semantics.

We need a report about what is actually used, and exactly how.

@NeonPurpleStar why?

@silverpill @liaizon What does this mean? “Follow redirects, but set a limit. Request must be re-signed after every redirect.”

do you mean I have to check the new http signature on every 30x response? I don’t believe that can work??

@liaizon Right now it’s two golang files that do a half-assed job at implementing activitypub

@liaizon yeah, it’s published, but currently I’d not feel comfortable being listed anywhere, the code is really rough and I haven’t really made sure it’s free of security issues

@liaizon Haha, that might be true. I did link it in the post, right now it lives at https://codeberg.org/Profpatsch/Profpatsch/src/branch/canon/users/Profpatsch/booster-bot and https://codeberg.org/Profpatsch/Profpatsch/src/branch/canon/users/Profpatsch/activitypub-go

@liaizon fwiw I made & deployed some security improvements, the current security mechanisms are documented in https://codeberg.org/Profpatsch/Profpatsch/src/commit/249aa389a2023814b328af8fc795750fd28d995d/users/Profpatsch/activitypub-go/security.md

maybe @silverpill wants to take a look at whether this all sounds sensible?

@liaizon @silverpill I want to write a blog post on this at one point, but I don’t know if I missed anything or misunderstand things.

@silverpill @liaizon Another issue I noticed: “set a max request/response size” means that we are essentially forced to implement paging of outboxes both on client and server