The implementation serves the application, not the other way around.
Lemmy would still be Lemmy, if overnight all insurances miraculously switched to a different protocol that provides the same functionality.
To say that it’s too difficult to implement is fair. I’d argue that this being so difficult would indicate a fundamental design flaw, rather than a user making an unreasonable request. Maybe a flaw was part of an intentional tradeoff, but that doesn’t make it less of a flaw.
An I going to personally redesign activitypub? No.
I tried to read the spec and i disliked it enough to stop before I got very far into it. But although I dislike the spec, I like the apps people built on it. For the most part.
And I strongly disagree with the sentiment that feedback is only useful if it provides solutions. I dont think that it is bad for OP to point out that this is confusing and seemingly punitive to the blocker, even without offering to fix it themselves.
You are still at the ‘this system is not perfect’ stage, which I agreed with many comments ago in this chain… and you have no solution, as I predicted you would not.
Do you want me to just validate the your ability to identify a problem, endlessly?
Do you need me to praise your ability to identify something we both already agreed that we both identified, what, days ago now?
Lemmy would still be Lemmy, if overnight all insurances miraculously switched to a different protocol that provides the same functionality.
If an apple transformed into the same apple, it would be the same apple.
… What are you saying?
A protocol with the same functionality would be the same protocol, and would not include any new features, like the one you think it is reasonable to request be added.
You have said a tautology and don’t realize it.
Further, it isn’t a design flaw.
It is a design paradigm.
The current paradigm is geared toward many communicating with many, aka, a simulation of a grand public square.
The paradigm you seem to prefer would necessarily be geared toward few communicating with few.
It would be primarily exclusive and impermissive, whereas the system that exists is inclusive and permissive.
You saying this is all a ‘design flaw’ is like being unsatisfied that an automobile cannot fly.
If you wanna drive, get a car, if you wanna fly, get an airplane.
If you want to endlessly dote that it sure would be neat if a hover car existed, sure, ok, you can do that, I am not stopping you.
But unless you are taking practical steps to achieve a hover car, then you are fostering a literally unproductive conversation, by definition.
Broadly, nearly all the time, I very much agree that user feedback is indeed very valuable and should be taken seriously.
But in this instance, what is being requested is very likely impossible to implement without a total, foundation level rewrite of the entire system (which would break and destroy every app using it), or, would necessistate the creation of an entirely different system.
This is because the requested change is antithetical to the core foundation of how the system works.
This is an engineering problem, a software engineering problem.
More people than myself have tried to explain how this particular request is basically impossible to implement without basically doing a complete rewrite.
So again, in this instance of this particular request, it is a very unreasonable request, that is not likely to be accomodated.
There is likely no way to make a system that is both capable of being freely federated and defederated, which also, somehow, has a grand, overriding, centralized, authoritative and authoritarian, total ability to prevent any users anywhere in the system from being able to view any other particular user’s posted content.
If you could design such a system that is somehow capable of this, that would be a revolutionary achievement in software engineering.
Failing that, we have to deal with the trade offs of different design paradigms.
You can have centralized control from the core of the system itself (and thus a core set of admins, who we all know never ever abuse their powers) and ‘personal safety’, or, you can have decentralized control in the hands of users and instance admins, and have only the safety of manually curating your own experience within the system.
When people ask for the kind of blocking system that we are talking about here, they do not realize they are asking for a centralized system, which is antithetical to the entire concept of what ActPub is.
I needed to step away for a week because this comment section was giving me anxiety.
I know we both agreed the system is not perfect.
I haven’t come up with a solution
and you refuse to acknowledge that treating OP like dog shit isn’t an appropriate reaction for a non-technical user complaining about the confusion behaviour of a poorly named feature.\
I came into this conversation because people kept mocking OP. I’ve been pulled off on tangents fighting about stupid shit because I can’t keep my eye on the ball worth shit, but that’s basically it. People are dragging OP for daring point out that the way “block” works here is confusing and feels bad to use.
Even if it cannot be implemented, it is not unreasonable for a user to request it.
I also absolutely refuse to acknowledge that blocking is antithetical to decentralized systems. Just because it’s not possible with the current design of activity pub doesn’t mean that it’s not possible in other decentralized systems. I’m not looking for perfection, I’m looking for improvement.
Here:
In mastodon, if Alice from instance A follows Bob from instance B, then instance B will send Bob’s posts to A. In addition to that, when B sends Bob’s posts to A, it can also send new block requests.
These block requests are public, and it is up to the subscribing instance to honor them, but it’s most of the way there, and instance admins can choose to defederate with instances that don’t honor it (like they already do with malicious instances).
Lemmy isn’t mastodon, but it still uses activitypub, so decentralization isn’t the limiting factor here.
With Lemmy it’s actually more enforceable, since content in a community is owned by the instance hosting that community. If Charlie is on instance C, and tries to reply to Bob’s post on instance A, instance A could have subscribed to Bob’s blocklist, and will reject Charlie’s reply because it’s in reply to Bob’s post. On Lemmy it doesn’t even matter if Charlie’s instance is malicious or not, as long as A isn’t.
Malicious is the wrong word, but I think you get the idea.
The implementation serves the application, not the other way around.
Lemmy would still be Lemmy, if overnight all insurances miraculously switched to a different protocol that provides the same functionality.
To say that it’s too difficult to implement is fair. I’d argue that this being so difficult would indicate a fundamental design flaw, rather than a user making an unreasonable request. Maybe a flaw was part of an intentional tradeoff, but that doesn’t make it less of a flaw.
An I going to personally redesign activitypub? No.
I tried to read the spec and i disliked it enough to stop before I got very far into it. But although I dislike the spec, I like the apps people built on it. For the most part.
And I strongly disagree with the sentiment that feedback is only useful if it provides solutions. I dont think that it is bad for OP to point out that this is confusing and seemingly punitive to the blocker, even without offering to fix it themselves.
Ok, so we’re still doing this apparently.
You are still at the ‘this system is not perfect’ stage, which I agreed with many comments ago in this chain… and you have no solution, as I predicted you would not.
Do you want me to just validate the your ability to identify a problem, endlessly?
Do you need me to praise your ability to identify something we both already agreed that we both identified, what, days ago now?
If an apple transformed into the same apple, it would be the same apple.
… What are you saying?
A protocol with the same functionality would be the same protocol, and would not include any new features, like the one you think it is reasonable to request be added.
You have said a tautology and don’t realize it.
Further, it isn’t a design flaw.
It is a design paradigm.
The current paradigm is geared toward many communicating with many, aka, a simulation of a grand public square.
The paradigm you seem to prefer would necessarily be geared toward few communicating with few.
It would be primarily exclusive and impermissive, whereas the system that exists is inclusive and permissive.
You saying this is all a ‘design flaw’ is like being unsatisfied that an automobile cannot fly.
If you wanna drive, get a car, if you wanna fly, get an airplane.
If you want to endlessly dote that it sure would be neat if a hover car existed, sure, ok, you can do that, I am not stopping you.
But unless you are taking practical steps to achieve a hover car, then you are fostering a literally unproductive conversation, by definition.
Broadly, nearly all the time, I very much agree that user feedback is indeed very valuable and should be taken seriously.
But in this instance, what is being requested is very likely impossible to implement without a total, foundation level rewrite of the entire system (which would break and destroy every app using it), or, would necessistate the creation of an entirely different system.
This is because the requested change is antithetical to the core foundation of how the system works.
This is an engineering problem, a software engineering problem.
More people than myself have tried to explain how this particular request is basically impossible to implement without basically doing a complete rewrite.
So again, in this instance of this particular request, it is a very unreasonable request, that is not likely to be accomodated.
There is likely no way to make a system that is both capable of being freely federated and defederated, which also, somehow, has a grand, overriding, centralized, authoritative and authoritarian, total ability to prevent any users anywhere in the system from being able to view any other particular user’s posted content.
If you could design such a system that is somehow capable of this, that would be a revolutionary achievement in software engineering.
Failing that, we have to deal with the trade offs of different design paradigms.
You can have centralized control from the core of the system itself (and thus a core set of admins, who we all know never ever abuse their powers) and ‘personal safety’, or, you can have decentralized control in the hands of users and instance admins, and have only the safety of manually curating your own experience within the system.
When people ask for the kind of blocking system that we are talking about here, they do not realize they are asking for a centralized system, which is antithetical to the entire concept of what ActPub is.
I needed to step away for a week because this comment section was giving me anxiety.
I know we both agreed the system is not perfect.
I haven’t come up with a solution
and you refuse to acknowledge that treating OP like dog shit isn’t an appropriate reaction for a non-technical user complaining about the confusion behaviour of a poorly named feature.\
I came into this conversation because people kept mocking OP. I’ve been pulled off on tangents fighting about stupid shit because I can’t keep my eye on the ball worth shit, but that’s basically it. People are dragging OP for daring point out that the way “block” works here is confusing and feels bad to use.
Even if it cannot be implemented, it is not unreasonable for a user to request it.
I also absolutely refuse to acknowledge that blocking is antithetical to decentralized systems. Just because it’s not possible with the current design of activity pub doesn’t mean that it’s not possible in other decentralized systems. I’m not looking for perfection, I’m looking for improvement.
Here:
In mastodon, if Alice from instance A follows Bob from instance B, then instance B will send Bob’s posts to A. In addition to that, when B sends Bob’s posts to A, it can also send new block requests.
These block requests are public, and it is up to the subscribing instance to honor them, but it’s most of the way there, and instance admins can choose to defederate with instances that don’t honor it (like they already do with malicious instances).
Lemmy isn’t mastodon, but it still uses activitypub, so decentralization isn’t the limiting factor here.
With Lemmy it’s actually more enforceable, since content in a community is owned by the instance hosting that community. If Charlie is on instance C, and tries to reply to Bob’s post on instance A, instance A could have subscribed to Bob’s blocklist, and will reject Charlie’s reply because it’s in reply to Bob’s post. On Lemmy it doesn’t even matter if Charlie’s instance is malicious or not, as long as A isn’t.
Malicious is the wrong word, but I think you get the idea.