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

@datenwolf @dalias @aeva would you go clean streets if they offered you money for that instead? I guess the amount is not relevant because everybody who makes food just does it cause they want to

@mbajur I think we are trying to standardize instance actors in an FEP, but I haven't heard of pure domain actor names

Edit: https://socialhub.activitypub.rocks/t/fep-2677-identifying-the-application-actor/3646

@mbajur maybe what you could try to do is serve your actor activity JSON from root, but I'd wager most webfinger implementations reject handles with an empty user part

@mbajur it's also kind of hard to parse cleanly and securely because Mastodon uses @user@example.com and others user@example.com, so hard to distinguish what's domain and what @ you can ignore …

@mbajur Ah yes, I’ve seen many people with single-user instances use something like @me@named.domain, which is super unfortunate because quoting them will show “@me”.

I think what you want to do has a lot of value here … so I guess the steps are:

1) implement webfinger to resolve @domain to the one actor, and @user@domain to point *to the same actor* (so you can mention them on platforms that don’t yet implement the new style quotes)
2) Publish an FEP about this new webfinger extension

@mbajur I’m just a little afraid of the case where you are replying to a toot that uses @domain nicks, because it might happen that they are dropped

It would be interesting to test whether mastodon links to people in replies by their href already, or whether it tries to do (cached) webfinger again when you hit reply, because if they use the href from the previous toot it could already work in replies.

@mbajur The other problem, as you can see above with @me is that if mastodon finds a nick on the local server, they will link it automatically, though I think you could argue that this is a misfeature from past times (it does not even open a dropdown)

@mbajur cc @silverpill

@jdlh @hongminhee @liaizon @Edent @north

Oh yeah, definitely I only do the validation on username selection, not when e.g. logging in a user or resolving webfinger.

But PRECIS is … precisely such a specification. Maybe not the best way to do it, I think @aumetra has a different approach based on unicode classes or something

@NeonPurpleStar I did not even know about this until now so I guess I'm on a successful trajectory

your daily dose of json+ld, #fedidev

@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