But these features were totally non-standard extensions right?

that's the thing, everything in activitypub is a non-standard extension. hashtags are an extension. post visibility the way it's commonly done is an extension (more like a convention in that it doesn't introduce anything new, but still not written down anywhere official), the concept of an un-locked account is a convention (and the marker that marks an account as locked is an extension). pinned posts, marking images as sensitive, they're all extensions

(surprisingly, this is the second time i'm writing this exact thing today)

It’s weird but it almost feels like the fediverse needs a benevolent dictator to kind of get an overview and set a clearer direction, when it comes to the standards.

this has historically been mastodon. and they have put themselves in such a place that anything they do not approve of gets seen as a "nonstandard extension" and anything they approve of gets seen as a part of the standard. see the above reply.

edit: additionally, emoji reactions are federated by the SECOND MOST POPULAR free/open AP software and has implementations in at least 5 other software families (not just forks of one software, entire software families). if they cannot determine a de-facto standard but mastodon can, is AP really an open standard?

this issue is a blocker for mastodon not supporting filtering remote posts by words (which would've helped with many spam attacks, which the pleroma family supported just fine for a WHILE via MRF, and more recently misskey has added support for)

if you go to socialhub you'll find MANY threads of reasonable ideas that are in json-ld representation bikeshed hell as people unnecessarily debate over which exact json-ld representation of the same exact data is the most correctest. the most infuriating recent ones i have seen is the emoji reaction fep discussion and FEP-fb2a: Actor metadata both of which does this bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY

Yeah, that is a shortcoming of the protocol. But it's necessary in order to be secure until things improve (and given this is AP, that's gonna be a while. People seem to love bikeshedding in circles instead of doing actual work)

Instead of sending the entire object embedded in the activity the secure way would be to only the URI instead. This is permitted by JSON-LD.

In the receiving side, if the object is untrusted (i.e. if it isn't signed or if it's from a separate authority from the parent object containing it) it should be thrown away and the id should be fetched from the remote instance directly (same as it would happen if it was a URI instead of an inline object). This is completely an oversight on Lemmy's implementation and not a protocol problem.

I seriously doubt Lemmy currently does any validation whatsoever. There were communities using this blatant security issue for non-malicious purposes (see https://endlesstalk.org/c/[email protected], which re-wrote posts from people (which is only possible if the posts weren't validated, or at least re-fetched from their origins)).

There is a way to re-share and validate remote activities, either through LD signatures (ew, JSON-LD processing :vomit:) (which only Mastodon and Misskey implement) or the newfangled FEP-8b32 Object Integrity Proofs (which nobody relevant on the microblogging space implements).

skill issue

i'm pretty excited for fedify since i'm unsure if there has been any other activitypub abstraction that feels as comprehensive as it seems right now (from a brief skim, anyway).

one thing i had in mind ever since i first skimmed the docs some time ago is this:

federation.setActorDispatcher("/users/{handle}", async (ctx, handle) => {

i would really recommend you to NOT tell people to use handles here. i assume this is just naming and the framework doesn't actually require a handle there, but documentation matters and if you follow on the footsteps of mastodon, pleroma, lemmy, and friends everyone who follows your docs will lose the ability to change usernames down the line without more pain than it's worth (and yes, there are software out there that allow it right now! please do not build fedi software assuming usernames are immutable jsut because mastodon doesn't let people do it)

just like how you wouldn't use a natural key in a database, you should tell people to use a surrogate key like an autoincrement id or a uuid on the actor IDs, as they're effectively permanent. while it may be probably fine for a quickstart thing like this to omit that, a lot of permanent codebases do start up by following these kinds of guides, and nudging people to do the correct thing when it's not that hard is always a good idea IMO

yep, definitely. i just thought "hey wouldn't it be funny if two dudes just ate some undefined substance because it's cheap" and, uhhh, yeah

i genuinely love it when people make their own meaning about shit i make sleep deprived out my mind because i thought of a funny word

Yep, all this ^^^

This is also one of the reasons why I believe ActivityPub client-to-server failed and will likely never gain much traction. It either needs every single client to re-implement all the features it wants from scratch, or the entire ecosystem needs to be dumbed down to fit a single mold. Leave all the unique functionality in "uncommon" software like (streams) and friends, even software like Lemmy or PeerTube would likely be extremely difficult to build in a world where client-to-server actually became a thing.

The only way I can see C2S actually taking off is as IPC protocol between an "app server" (which would be the equivalent of Mastodon or Lemmy or (streams)) and a "federation server" which is just a dumb pipe that distributes and receives objects and activities, and even that has it's fair share of concerns, both around efficiency and the same "dumbing down" problem.

most people on lemmy do not understand the tradeoffs both activitypub and it's implementors do, as evidenced by this exact community we're in. these memes wouldn't gain any traction even if they were funny to their intended audience (which i have doubts on if it's possible to do but idk i'm not creative enough)

id argue none of those are fun topics you can joke about but "memes as a form of outrage" (aside from, like, two) which is already a problem (see all the political memes on any of the meme communities for countless examples) we do not need to encourage imo

to be fair there isn't that much about the fedi in general that you can meme about. the closes you can get are in jokes but:

a) lemmy doesnt have them because this place is uncreative and only serves as a dumping ground from memes from other places when they aren't bickering about politics
b) in jokes of different parts of fedi do not translate well just because they share a protocol, given the extremely little overlap on people here
c) they're not really "fediverse memes" just because they happened in the fediverse, are they

Make emojis optional so you can still up/downvote

modern not-misskey implementations of federated emoji reactions do separate likes from reactions, if lemmy doesn't want to reinvent the wheel (they have no reason to!), this will most likely be how it'll work

upvoted but realized which community this was posted so i had to un-vote (i think thats how it works here)

emoji reactions and especially actual custom emojis that are not broken inline markdown images are one of the defining parts of the actually fun parts of the fedi and not having any (even as an option you can disable) just makes this site look even more of a boring politics shitflinging and linux evangelism platform instead of somewhere you can expect people to relax and have fun at

they are way less of a distraction than replies with reaction images and 10 gigabyte animated gifs which take up half your screen and seem to be favored by the people here considering the negative reactions (ha!) this opinion got

i'd also be in favor of MFM, too. doing MFM art is much more of a creative expression than shilling firefox or grumbling about how the US is falling apart

just,,,,, please implement them correctly and in an interoperable fashion, and not like the broken mess of a custom emoji system lemmy has today

this is what it feels like reading a post from a mastodon.social user except they have a character limit of like 2 so instead of separating the #hashtags they will #PutThemInline #LikeThis so you get an #aneurysm reading a post

iirc mastodon was implementing smithereen's flavor of groups. no idea if they ended up changing course or anything (not following masto dev tok closely) but the way they work is fundamentally different from how Lemmy and compatible groups work

from what i can tell (from the work in progress pull request) mastodons group implementation explicitly does not aim for compatibility with lemmy

other than that, i agree on activitypub being crap in terms of making interoperability easy

the specs are so open ended that i doubt real interoperability will ever happen. you can break interoperability with basically every other current software out there and still be compliant with the specs

that post will have been a text post, not a link (those are likely broken now, and certainly were broken a year ago due to a bug in the misskey 12 codebase inherited by firefish and forks. modern versions of misskey just fixed that a couple months ago)

the username thing does not completely break federation, but it will randomly confuse instances. there's a 50/50 chance whether an instance will get the correct user it asks or not, and once an instance resolves a user once it'll have a similar 50/50 chance for each profile update (icon change, sidebar change, etc.). of course, if there's no conflicting user for a community (or vice versa) then federation will be fine.