I’m not a native speaker so I don’t hear the fart association so much. But isn’t tooting also just what a trumpet or elephant does? In that way it makes sense. But I do think the terminology is a bit silly. Why not just “post” instead of toot? Why not just “repost” or “share” instead of “boost”? It feels a bit too much like corporate social media where every feature needs a “wacky and fun” name.

Yea I see what you mean. How do we solve this though? I mean let’s say you were to redesign the protocol from scratch. Do you just need to include all these things into the protocol from the start? That’s a lot of features and considerations to make. An extensible protocol might be for the best? But it does bring a lot of complexity… I’m really not sure.

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 see gets seen as a part of the standard. see the above reply.

Yea this is problematic, especially because this pulls AP into a more microblogging-oriented direction, at the expense or at least disregard of all other use cases. I would not call this a benevolent dictator - that’s just a regular dictator.

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

Where? I’d love to read more about this stuff.

I recently started looking at socialhub actually. I have even participated in that emoji reaction thread you linked, but I only joined the site recently.

Honestly, I’m a bit confused by the site. There’s kind of a lack of direction in a sense? Everyone is trying to extend the protocol in various different ways and it seems difficult to achieve alignment and agreement. I guess that is to be expected in a decentralized system but still.

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

What’s the alternative though? I mean nobody has the authority to put their foot down and decide. I agree that the debates go on for way too long, but how else do we find alignment? Then again, the long discussions definitely exhibits a kind of selection bias - only the people who are pedantic enough to keep discussing will do so. Everyone else naturally just get tired of the whole thing and leave.

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 bullshit ON FEATURES ACTIVELY FEDERATING RIGHT NOW, where changing it would BREAK BACKWARDS COMPATIBILITY

But these features were totally non-standard extensions right? You can’t expect such things to continue being compatible as the actual standard evolves. It would also be a neat way to strong-arm the standard - just implement an extension in the way that you want it to work and now the standard has to keep your version compatible. That wouldn’t be good. Just because there exists a non-standard implementation does not mean it should be able to dictate how stuff should be done.

Yep exactly, it also leads to Mastodon instances only seeing local likes for remote posts. You’ll never see remote likes on remote posts as they wouldn’t be sent to your instance. I honestly don’t understand how this hasn’t been a bigger problem for Mastodon, but I guess Mastodon is more about boosts and chronological timelines and less about sorting stuff based on likes.

So is it an emulator? Or does “translation layer” mean something else?

and given this is AP, that’s gonna be a while. People seem to love bikeshedding in circles instead of doing actual work

Out of curiosity, what do you mean by this? Any examples? I’ve not followed the development of AP very much at all honestly so I don’t know the history.

(mentioning people mentioned in post because post mentions apparently do not work)

@bstix@feddit.dk @TDCN@feddit.dk @Plume@lemmy.blahaj.zone

Mastodon doesn’t support groups so it’s maybe not a “bug” per se, but it is at least a missing feature.

Consider also that if Lemmy shared upvotes the same way, you would only see the upvotes on posts from your own instance, i.e. upvotes would only appear on the local feed. The all feed would be pointless and in general it would be pointless to try to sort posts across the whole fediverse, as you only receive upvotes for your local posts.

Lemmy simply would not function if it shared votes like that. So in that sense, it’s a bug kind of. And as mentioned above, I think it’s a bad way of doing it, as it encourages centralization.

Once every two minutes is plenty,

That won’t work, because it would have to be once every two minute for every single comment and post forever.

You have a point about new sort, but you could approximate it by sorting what’s known to an instance. It’s not ideal, but it’s at least something. Maybe it would make sense to push just that feed, or to fetch a subset periodically.

I have no idea what you mean by this - you can’t fetch a feed, that’s not at all how the data is organised.

If someone on Mastodon likes a post on feddit.dk, I don’t see any reason feddit.dk can’t communicate that to lemm.ee when I go look at it.

The problem is this: How does lemm.ee know that the like that feddit.dk claims is from mastodon.social actually is from mastodon.social? What prevents feddit.dk from just fabricating a like from mastodon.social? Currently there is no nice mechanism for authenticating such a forwarded like. A malicious instance could send loads of likes claiming they come from other instances.

I don’t understand why your instance seems to be rewriting the link somehow, but it shouldn’t. This happens with lemmy-ui?

The way you describe this, it sounds like it would need to work on trust a lot more than it already does. What if there’s a malicious instance actively circumventing bans, ignoring any pulbished banlist?

As for sending the post, it’s not that hard to keep track of all servers that follow a group or person or hashtag

I was talking about the scenario where you are instance A and you don’t know the followers of a user of instance B. That is not easy to keep track of, since you obviously don’t get any of the follow requests for a user on another instance.

Interesting. Seems like Photon attempts to do some kind of clever (and entirely non-standard) hack and tries to load the comment from your own instance? But obviously you need to see it from Feddit.dk to see the votes. This is a bug with Photon I would say.

Weird, what client are you using?

If you have a signature you can also sign the contents, so you wouldn’t need to download the content. But AFAIK ActivityPub has no mechanism for including signatures in objects as it is right now. There’s only HTTP signatures, which aren’t on the object itself.

ActivityPub was designed for social networks, not for forums.

If you ask me, forums are social media. I think it’s very prescriptive to say that forums should somehow not be supported by a social protocol. I’m not really sure how ActivityPub was designed, but in some ways it feels like they tried to make the protocol too flexible and somehow they managed to make it not flexible enough in other areas, or at least somehow didn’t think to support other use cases very well. It’s unfortunate.

The alternative, in my opinion, would be shared inboxes combined with adding the “public” audience to outbound messages.

So with this model, when I post to, say !technology@lemmy.world, my own instance would send the post to all the instances that I know of? Or would it send to only those instances following that community (how does my instance know that?)? I think there’s also the problem of how moderation is handled - I mean, how does the community in question enforce bans for example? With the current model, the community is kind of “in control” of everything happening, because it is the one sending out the activities. But if everyone sent them themselves, that seems less clear. What if the community defederates an instance but my instance doesn’t defederate that one - will my instance send the post to the instance that is defederated by the community? It’s all very complicated. I’m not sure what a good solution is.

That would still be directly from one server to another server. I.e. from A to B and from A to C. But forwarding is a different matter, i.e. A sends something to B which sends it further to C. There’s complications with signatures and verification in that case and it’s less clear how to handle that.

Yes, fetching the URL directly would be a way to verify it. I don’t know if Lemmy currently does that. In any case, it seems very round-about.

But that’s how ActivityPub was designed?

This design is incredibly badly suited for something like a forum or content aggregator, such as Lemmy. Only sending Likes to the direct receiver means that other instances are unable to sort content based on votes accurately. Mastodon unfortunately doesn’t care much about this since they prefer chronological timelines, and then Like counts and such don’t matter as much.

It’s really sad that ActivityPub, a supposedly very flexible protocol, seemingly is made mostly for microblogging and doesn’t support other use cases very well at all.

Are groups going to be implemented in Mastodon by replicating the crazy “pretend there’s an account boosting everything that’s happening on the server” behaviour?

Call it crazy but what other options are there? And honestly it is entirely within the spec so it’s not that crazy.

The crazy thing, if you ask me, is that ActivityPub does such a poor job of modelling something like a subreddit. Modelling a subreddit as a Group of users who are subscribed to that subreddit seems unnatural. Most people would say a subreddit is more like a category for posts or a collection of posts.

however they than just forward this reply to the follower collection

How do the receivers of this indirect activity verify that the activity was indeed produced from the original instance?

That would be a way to do it, but it seems needlessly wasteful as it requires an additional HTTP request. But yea, that could be a way.