I’ll be interested in following this thread. Some customers of mine are tired of Pixelfed thousand little papercuts and are considering dropping entirely. Even one photographer preferred to run their own Mastodon instance to avoid dealing with Pixelfed’s eternal beta status. I might spend some time this weekend figuring out how difficult it would to deploy Vernissage.

Best person to answer this is @mariusor@metalhead.club

True, you’ll need an activity object whose actor is the same as the original post creator to indicate the answer is accepted. The point still stands, though: the ActivityStreams vocabulary already has what’s needed to enable this funcionality.

Ok.I see. Personally I don’t think it’s a good idea. It’s only a marginal benefit in terms of protection against data scrapers (you can also build that profile based on who they follow, or what they write about…) and it makes things more difficult for moderators and hides important information from other community members.

Stop thinking in terms of “votes”. Think of the activities as a “fixed content messages”: John liked this. Alice liked that. Bethany did not like that other thing. Each “vote” is a meaningful interaction. A server that says “2734 people did not like your message” means absolutely nothing.

This is not a political council nor a popularity contest. No one will make critical decisions based on the amount of worthless Internet points.

I do not understand arguments about privacy when we are talking about a public, social network. Social interactions online do not need to be that different from real-world interactions. if you are not willing to say “I did not like / I disagree with you” to someone personally, then you shouldn’t say it at all.

Sean proposed something more ambitious: identity-first onboarding, where you import your social graph and content before choosing a server. The idea: set up a “pre-identity” that pulls in your posts and connections from other networks, then pick a server that fits

https://fediverser.network/ has exactly this. The missing piece was (still is) that no lemmy admin that I talked to bothered to integrate with it.

I understand that coming from users, but not from the project developers. They know they’ve built a client for the Mastodon API, so it should be described as such.

I was super excited when I saw the headline because I am just about to deploy a headless ActivityPub server, then I realized it’s a client for the Mastodon API.

I’ve added the “without any justification or discussion about the merit of issue at hand” as a qualifier…

It’s totally fine if you say “yes, this looks cool but I don’t have the time to do it”, or even “I’m not so sure about it, but if you bring a PR we can take a better look at it”.

maximum anonymity, but this was widely disliked so it was dropped.

Maximum anonymity is a lie. Users still need to trust the server admin. The truth is that the Fediverse is not a secure/private messaging platform, and attempts to hide this from the users might be well-intentioned but will bite the devs in the ass, sooner or later.

this has vast fediverse support because it enables community modularity, which is needed in a world where instances will go offline, causing communities to be orphaned.

To solve this it would be better to have the PieFed team pushing/implementing the appropriate FEPs (FEP-7952 and FEP-EF61) instead of an-hoc hack.

This was agreed with the moderators of said community.

Not the point. The point is that the devs are taking the “everything and the kitchen sink” approach to features, prioritizing any type of functionality that is minimally useful to the users instead of putting some effort on the harder stuff.

I have suggested (lemmy-federate) be opt-in rather than opt-out.

Doesn’t matter. Admins will see it, think “that is nice!”, turn it on and only realize later that their database is completely bloated with data that is not really needed. Meanwhile, the real problem of content discovery could be solved by implementing pull-based federation and client-side caching, but again this type of work is not being done because it’s not something that the users see directly.

Off the top of my head, piefed is:

• Sending pseudonymous actor ids to hide votes
• “Migrating” communities by re-creating activities and objects on their own server, just rewriting the URLs and pretending the piefed server actually was the original source.
• Integrating functionality that is hardcoded to specific instances/groups (auto-posting new communities on !newcommunities@lemmy.world)
• Integrating lemmy-federate directly into the instance - which is a horrendous idea if you consider that will lead to every piefed instance holding every copy of the messages, even if no one in the instance actually follows or interacts with it.
• Proposing a completely out-of-band and a custom activity protocol to notify moderation reports
• generating a JSON-LD document filled with unspecified terms.

I am not here to gate-keep anything. If the devs are having fun working on it and if the users are happy with the product they are getting, more power to them.

It might be that piefed gets enough users and outside interest to force the team to be more discipline and mature about their practices, but to an outsider this looks more and more like a bunch of amateurs building stuff for fun, and not something that can become a viable alternative for a open social web.

Why should I take on the burden of acting as QA and standards-compliance supervisor for a project that I have no direct interest or stake on? Especially when the attitude of the developers is “throw something out there that works, if someone complains we revise it later”?

There’s enough living humans to post news articles and memes.

But there are not enough humans talking about interesting things that are only being discussed on Reddit.

Besides, “news articles and memes” are the least interesting thing to have in a discussion forum.

What’s actually missing here?

At the very least, it is missing a context definition in the JSON-LD document that describes the term. What does a document of type ChooseAnswer mean if the provided @context entry only makes references to activitystreams and security/v1 namespaces?

More than that, it is missing a clear need. There is no need to specify a new vocabulary term when as:accept is right there: Why define a new term when something like

{  
         "id": "https://piefed.social/activities/answer/hgb4iO4b8UAFRTn", 
         "type": "Accept",  
         "actor": "https://piefed.socialz/u/rimu", 
         "object": "https://piefed.ngrok.app/comment/224",
         "target": "https://piefed.ngrok.app/post/123",  
         "@context": ["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"],  
         "audience": "https://crust.piefed.social/c/linux_questions",  
         "to": ["https://www.w3.org/ns/activitystreams#Public"],  
         "cc": ["https://crust.piefed.social/c/linux_questions"]  
}  

can represent the information that a comment has been accepted as a good answer to the question?

Believing that the we need professional hosting providers to have a sustainable Fediverse != “Monetizing the platform”.

Besides, I’ve already voiced similar concerns through different venues. The devs made it clear they are not interested in developing software with a focus on standards compliance. They care about throwing as many features as possible to their system.

It’s fine, it’s their project, they can do whatever they want. It doesn’t mean that I don’t have the right to have an opinion about it.

You can have “modular communities” without violating basic compatibility with the standards. But it is harder to do it and the end users don’t see the potential issues, they will gladly cheer you to do it in the easiest way.

‘ChooseAnswer’ is not an object type defined by activitystreams, and the json-ld context provided by PieFed server has no extension referring to it.

This means that any server ingests messages to an inbox using RDF will see this document and think “this is invalid” and drop it. If it sent as:accept instead, it would work without any modification.

Re: community migration, there is at least one other person besides me that said “when I post something to one community, and PieFed says that I also said that on another place when I didn’t, then the server is fabricating Information”.

To illustrate the point: if suddenly we adopted JSON-LD signatures as a message authentication system, then all messages from imported communities would fail.

How is creating a new Activity type preventing compatibility with the rest of the Fediverse?

If they chose to use any of the 3 solutions I described, there would be no changes on the other servers to receive and parse the message. But because it uses a different type, now those serves that want to store the information about an answer being accepted have to write code specifically to handle messages from PieFed.

It also works in the other direction: if I want to send an “accept” activity for a comment, I could do it from my server and PieFed could easily understand it as well. But because they want to create their own ad-hoc solution, then they won’t be able to.

When you’re the first one doing something with ActivityPub, you have to create it yourself.

No, you don’t. The whole point of Linked Data and RDF is that nodes can send data to each other without having to agree on any new protocol

Piefed features inspired by existing implementations such as the emoji reactions

You are only making my point. Emojis have already a defined extension, this is why it’s easier to adopt it.

picking the one feature

It’s not just that. They also proposed some ad-hoc activities for moderation in the past and their “import community” works by taking posts and rewriting them as if they originated in the piefed instance. These are all signs that the devs either don’t understand or don’t care about JSON-LD as an standard.

This is not a matter of “opening a PR”. The fact that they are adding features in this completely ad-hoc manner shows that they are prioritizing features for piefed over interoperability with the wider Fediverse. If my job was to go around convincing every AP developer that their approach is flawed and to fix their mistakes, I’d be doing nothing else with my life.

What I can do though is to create a framework that makes it easy to work with JSON-LD and occasionally file bug reports.

An aside: this “feel free to open a PR” - without any justification or discussion about the merit of issue at hand - is the standard passive-aggressive response from every developer who is not interested in making the change. It’s sad to see that it’s also becoming the go-to retort for the project cheerleaders…

It’s this kind of thinig that makes me think of PieFed as just a pile of hacks with no serious consideration for the Fediverse

Designating which comment is an answer involves federating a new Activity:

{  
         "id": "https://piefed.social/activities/answer/hgb4iO4b8UAFRTn", 
         "type": "ChooseAnswer",  
         "actor": "https://piefed.socialz/u/rimu", 
         "object": "https://piefed.ngrok.app/comment/224",  
         "@context": ["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"],  
         "audience": "https://crust.piefed.social/c/linux_questions",  
         "to": ["https://www.w3.org/ns/activitystreams#Public"],  
         "cc": ["https://crust.piefed.social/c/linux_questions"]  
}  

There are at least three different ways to implement this in a way compatible with ActivityPub:

1. Send an “as:accept” activity with the comment as the object.
2. Add an attribute for the comment indicating that it has been selected.
3. Create a collection for chosen answers, add to the post object.

And even if this type of new activity was a necessity, they could add their own extensions via a proper JSON-LD context definition. But they completely disregard JSON-LD, which means that they expect other servers to either (1) adopt their ad-hoc vocabulary or (2) ignore it completely and keep this idea that “Only PieFed has these features”.