Difficulty accessing federated communities, reading and posting from/to communities not on your instance is confusion (or maybe impossible ?) #3033
Comments
|
I second this! lemmy.ml are screaming it to use Federation but Federation is not apparent to the average user and leads to competing communities of the same name as given with the Montreal example. I have figured it out though. The default view are for the 'local' communities on that particular server and you have to press 'All' in the communities section to find the others. I would say that this is a terrible default, it should be 'all' that this server is federated with (and if some servers host questionable communities, then the admin of that server could surely decide not to federate with them?) One you have figured this out the URLs in this example are: https://lemmy.ca/c/montreal and https://lemmy.ml/c/montreal and https://lemmy.ca/c/[email protected] are the same community I would go further and say that the full URL of the instance should be presented even on the instance you are already on, for example: https://lemmy.ml/c/montreal should become https://lemmy.ml/c/[email protected] as it's default URL to save confusion |
|
This is a serious problem, this makes every "/c/montreal" its own tiny Island of people writing into the void and never being read by anyone. Except for whichever happens to be "the big one". Am I correct to believe, there is no way to ask an instance to show all "/c/montreal" from all federated servers ? In my opinion, the default behaviour of lemmy.example.com/c/montreal, should be to show all posts from all /c/montreal communities on the entire fediverse. This way you can post to /c/montreal on any instances and it doesn't matter, it's just where the data is archived. But then, how are people going to comment on your post, if they have to create an account on every single instance before they can post ? This is an extreme amount of friction that will not be tolerated by users by most users. |
|
I believe this is relevant as well: LemmyNet/lemmy-ui#1048 |
Just a note, in your user settings in Lemmy-ui you can select which view (subscribed, local or all) is your default. It's listed in the settings as "Type". If you want to default to All, set it to All and save. Going back to the home screen and you should see it selected appropriately. |
|
This issue does not seem to have a clear problem as the initial premise is flawed lemmy.ml and lemmy.ca's c/montreals are different. |
|
It's implausible that anyone on lemmy.ml or lemmy.ca who are visiting /c/montreal, actually want to visit specifically different places. The default /c/montreal should display the same content regardless what server you're on. I you really want to limit to server local /c/montreal content, then you'd activate a "show local content only" filter. Or visit a local specific url like maybe "/l/montreal" The current way this works is backwards, as if what was server local was what mattered and what was fediverse global mattered so little that the software is currently lacking an option to see it entirely. The obvious result this will have is centralize communities around a single instance and preventing small communities from taking root entirely, since they won't even be able to find each other. |
|
@lionirdeadman you have taken the objectively wrong position, just because you don't get it. |
No, that's how it's designed. ![email protected] and ![email protected] are different communities, run by different moderators, with different rules. You can view either from any Lemmy server that's federated with them (i.e. the vast majority of them). |
|
@29039 This is a fundamental misunderstanding of how Lemmy and other federated services work. The fully qualified form of a given board includes both the board name and server hosting it, as each server can host its own boards with potentially conflicting names. You can think of it as similar to email, where for example In case you're wondering - the same problem is solved by decentralized networks such as blockchain platforms, BitTorrent, IPFS, etc. by just... not giving anything a human-readable identifier by default, and instead making its fully qualified, canon ID just a cryptographic hash that can then be looked up via DHT, via full access to the blockchain history, whatever else. Lemmy/Fediverse is of course not "decentralized" in the same way, rather "federated", but just a point of comparison for you |
|
I am not conflating lemmy with how email work. I am the one telling you "nobody wants lemmy to work like a mail server" When users ask /c/montreal, they're not asking for only the /c/montreal of one instance. I think the moment new lemmy users understand this paradigm, they understand "oh no, this is reddit with extra steps". And then they just go back to reddit because, if you're going to be stuck in a fiefdom, you might as well be stuck in the biggest one. The reason why I'm writing here, is that I don't want lemmy to be a failure. If you go right now to https://lemmy.ml/c/montreal you can see it in action It's not working. It's obviously not working and will not ever work. The change is easy, user that go to https://lemmy.ml/c/montreal get to see the WHOLE fediverse's /c/montreal. That's every single post and comment on every single lemmy instance on the fediverse. There really is no way around this, if you can't agglomerate the whole fediverse in one page, then there is no fediverse, there is no decentralization, there is only reddit with extra steps. (and no multi-reddit-likes will not fix this either) |
Is that really correct @29039 ? Maybe you don't, and you have the right not to want it. To be clear, none of us have anything against centralized services like Twitter, Reddit, etc. and if that's what you prefer, we fully encourage you to find such a service and join it.
Nobody here is trying to "replace Reddit" or "become the next Facebook" - a lot of us are emigrees from centralized services, yes, and sometimes that refugee's animosity shows, but I really don't think any of us are approaching this from that corporate advertising school of thought. The idea of doing it this way is that nobody has the right to create a single /c/montreal and snatch it from everyone else. There is not one /c/montreal controlled by one set of moderators from one instance. This is a design choice that we, as members of the Fediverse, believe is ideal. We're not going to compromise on it. The idea of the Fediverse has always been that users sign up with one instance, but can communicate with each other across multiple instances. What you're describing is closer to how e.g. hashtags in microblogging Fediverse services like Mastodon want, but for link-aggregator services like Lemmy, I think overall people value being able to create their own communities.
Relevant reading: Zooko's triangle It's not a perfect solution, but the conjecture states that no such solution exists. It's a compromise that we, as the members of the Fediverse, are willing to make. We're fine with slightly clumsier names if it means more control and agency over our communities. We're not demanding you agree with us, but we're not backing down on our values. |
|
I'm sorry if this comes off as aggressive or confrontational - I don't mean to sound that way. If that's how I'm coming across, please let me know. Ideally I'd just like to shed some light on what we're even trying to accomplish here. |
|
I'm having a hard time explaining this, I thought this was really obvious. Yesterday I explain basically how lemmy works to my friend and I didn't even need to finish he saw immediately that this was the problem. That this was such a big problem that it's not going to work because it doesn't solve the basic problem reddit has. Suppose you're a new user on a random instance, let's say https://lemmy.loungerat.io You go to https://lemmy.loungerat.io/c/montreal on your server and you get an error Suppose the user doesn't give up right there. They create the community and post something, but no one ever sees it and they never get an answer. Other users go to /c/montreal and they don't see that first user's posts, they see the error, or their local version of /c/montreal, which doesn't show external content. The users might then go to their search pages https://lemmy.loungerat.io/search?q=montreal&type=Communities&listingType=All&page=1&sort=TopAll And they're going to find, nothing
But then they'll google it and they'll find And then they will realize the big problem with lemmy. The big fatal flaw There is only one /c/montreal and it is on lemmy.ca If you post anywhere else/c/montreal , no one will ever see it. They will never see it because they would have to already know about it and already be subscribed to it. The result is already happenning, each community is centralized around a single instance. Because if you post elsewhere, no one will ever see it. This is what I mean by "this is reddit with extra steps" Power over that community is again the subject of a tiny group of owners. Yes you can say "if the moderators are jerks, the community can just move" . That's nice in theory, but in practice any community on reddit right now could "just move" to lemmy. Except, in practice, no they can't. And that's going to be the same on lemmy because the communities are rooted on centralized servers because if you just go to any random instance and start writing on /c/montreal, you are invisible. It's pointless to write anywhere other than "the big instance" BECAUSE yourserver/c/montreal doesn't show you the entire fediverse by default. |
|
Alright, I am going to spell out the problem because it seems like there is a big chasm in understanding. Advocates of the problem are here |---------------- and programmers are here -------------------| @shodanx2 and I have the same view on this. This is not a "bug" as such. The code is working as intended. This is a fundamental design flaw. If you are just into code looking for programming bugs without any concern for how the application is designed in the first place, you are not going to get it. Context: Lemmy is advertised or at least perceived as being an open-source alternative to reddit, which addresses the shortcomings of reddit by offering federation - which is supposed to mean that if one server admin is misbehaving, it would be straightforward for other server owners to remove that server from the federation and the communities will not be disrupted, nor will there be any loss in data. To an extent, the same is true for misbehaving community mods - a community could rehome onto another instance. From time to time, there is going to be mass sign-up events when reddit does something monumentally stupid, followed by a co-ordinated call to "Switch to Lemmy". We recently just had one of these events because of the "API/3rd party app" issue, and because the Lemmy ecosystem was not prepared to handle this, it failed to bring much real traction to Lemmy. Reddit are planning an IPO sometime later this year, and this is likely to cause another influx into Lemmy. There will likely be other chances as well, as reddit constantly make unpopular changes to their site. When reviewing why this mass switch to Lemmy failed and in what way Lemmy is not prepared to handle this, from what I can see, the main co-ordinated message coming from reddit was "use Lemmy.ml" I don't know anything about the folks who run the .ML server, but essentially their message was that their server was overloaded, go and sign up on a different Lemmy instance because they are all federated anyway, and prevented any more signups. Perhaps there needs to be special effort to bring .ML server owners on board with this, but essentially what this has caused is dozens of tiny and fragmented Lemmy 'communities' across dozens of servers, or not even being able to find the designed community and giving up (most likely), because the Lemmy namespaces are counterintuitive. The user expectation, particularly of ex-reddit users, would be that the /c/community part of the URL is representative of one big community which is federated across servers, and the https://lemmy.ml/ part just happens to be the federated endpoint you are using to access it. When looking at the problem, you have to take off your developer hat and wear the lens of "How would an average user see this?". This was not a straightforward user experience to be able to just sign-up, find their favourite community again, and just start shitposting. Luckily the design of Lemmy already has the necessary design in it to accept @lemmy.ml as part of the community's name - to be clear which server the community is currently homed whether browsing on the home server or not. So really so solve this massive friction problem it is just a UI issue to prefer the Federated ecosystem (default to All over Local, default to full @ URLs even for locally hosted communities) instead of focusing on each server. The only changes I am currently advocating for are:
This doesn't actually remove competing communities of the same name on different instances - there will still be two c/Montreal communities - The difference is that to the end user, it will be simple to see that there are two c/Montreal in the directory, one of 53 users and 3 total posts, and one of 563 users and 58 posts, and they can decide which one to be a part of, and be able to easily access that same community no matter which instance they are on, while also being able to access the competing one. Bigger is better when it comes to communities, the more active users in the one community, the more momentum is gets to grow. There is nothing fundamentally different between the two /c/montreal communities and most likely this was made like this due to not understanding how Lemmy federation works, as opposed to a deliberate choice of being separate. It is an unnecessary fragmentation which harms both communities - users who accidently ventured to .ML's /c/montreal would accidently think that the /c/montreal lemmy community is inactive, when in reality the more active community is just homed on a different server than the most popular one. There are other fundamental design changes which will be needed as time goes on, as to how to handle server admins or community mods who are deficient. And I have ideas on how that could be solved with community self-moderation similar to Slashdot, but for now this is the main problem in even getting started to bring communities together and re-find their home whenever they flee from some other site. |
|
I agree with your diagnosis but not your solution. homeinstance.com/c/[email protected] or anyinstance.com/c/[email protected] But if you go to homeinstance.com/c/community or anyinstance.com/c/community This should display all /c/community content stored on all federated instances And I expect, for any communities, most users will mostly access homeinstance.com/c/community And for any /c/community, I would define success as having /c/community content on thousands of instances. I would also expect many instances to simple mirror other communities, post and comments included, as local content. This means the "full spectrum" client would need to deduplicate posts on the fly. Also, moderators should emit moderation opinion about posts and comments not stored on the servers they own. Also, basically every lemmy power user should do a small amount of moderation on the fly and clients should agglomerate such moderation opinions on the fly and turn them into moderation action right inside the lemmy user's client as part of it's locally running content discovery algorithm. |
I agree that this should be an ultimate goal to be able to do this, but for now it is not practical until distributed moderation is working, otherwise:
|
|
I agree those second order problems of a truely federated community are important and we don't know the right solution to those problems. I think the way forward is still to have anyinstance.com/c/community show the entire fediverse by default and then let the real problems with this automated (dumb) agglomeration show themselves and then find a proper solution for them. I think the solution mostly lies in having a more sophisticated content discovery algorithm which better serves the user in a personnalized manner. If anyinstance.com/c/community is "raw fediverse" that content all possible good and bad stuff that can be posted, there is far too much content to fit on a tiny cell phone screen. There is always an algorithm that decides what goes on that screen and in what order. This is where moderation happens and all actions that happen here must happen on behalf of and with the implicit consent of the user. There should even be a log somewhere where the user can go and review all the decisions taken under the hood and the user should have controls over all the levers of those decisions if they are not to the user's liking. The content discovery algorithm should scan the content for things his user dislikes and reduce the probability of displaying it. People who rawdog the lemmyverse should be able to emit moderation opinions that will then be picked up by the content discovery algorithm, for instance upvote/downvote/follow user/block user/follow community/block community. When multiple users emit the same opinion regarding a community, post or comment then above a certain dynamically adjusting threshold, the content discovery algorithm would weight down content with a "generally negative moderation consensus" (and weight up in the reverse). The content discovery algorithm should also have anti-fudging provision for instance, for each user it encounters that has emitted moderation opinions, the content discovery algorithm should examine that user's history of post, comments and moderation opinions and give some "genuineness" and/or "alignement" score to that user. And then weight all opinions of that users with that weighed modifier. The content discovery algorithm's user, should be able to see and adjust those weights. Imagine that a trusted community member is seen by the user as especially trustworthy, the user should be able to "subscribe" to that user's moderation opinions and tell the content discovery algorithm "give 100% weight to all moderation opinions of that user". In this world, we subscribe to moderators, and default moderators are elected by a consensus of subscription. I believe that building a content discovery algorithm of this level of sophistication is going to require running a small Large Language Model locally on the cell phone's GPU. Maybe the open source LLM Falcon-RW-1B could be used for this purpose due to it's small size (1,3B) which should run on the tiny GPU found in most cell phones. It might make sense to have community operated LLMs, scouring the lemmyverse and have them emitting public moderation opinions regarding daily posted content, so as to help bootstrap the content discovery algorithm that would live inside cell phones with a GPU unable to run local inference on a GPU. In any case, the moderation complication of a "raw accessible lemmiverse" should be treated as a separate issue. We cannot worry about filtering something that does not exist yet. First make the whole lemmiverse visible, and then we can worry about filtering out the bad bits without resorting to the explotative and oppressive tactics of Big Tech moderators. |
|
@shodanx2 I like your idea for long term but I think that we are biting off a bit much by asking for all this up front. This is a lot of dev work. Personally, I would put these ideas into a different topic and delete it from here, because this is just going to confuse the immediate problem and deeply put it into the "won't fix" pile because it is asking for too much dev resources for a project still in the early stages. Let's focus on making Lemmy usable to build communities by fixing the immediate problem with a straightforward fix, and when Lemmy has the popularity, it will then become justified to put in the dev time for a full distributed moderation/viewing algorithm system. I also don't agree that we should purposely make a bad system to cause an "impetus" to fix it. In this infancy stage this is just going to scare users back to reddit if it looks like an unfiltered cesspool. Let's get a following first and then build on that. We can get Lemmy working "good enough" to accept the userbase with just the 3 simple points I made earlier. |
|
I agree, I only included all of that because the option to access the "raw lemmyverse" raises the question of "what about moderation ?" This is my answer to the moderation question. But for now I just want every day users to have access to the raw lemmyverse and that it should be easy. Yes, we will have to avert our eyes to the stray penis or swastika until distributed moderation becomes possible. But I think we need the raw lemmyverse as soon as possible before the idea of "the big instance" and "the big community" becomes ossified in the lemmy structure. |
|
if you want a raw lemmyverse, I think that's on you to go to each lemmy instance to find them, or at least contribute the code. I know that there is demand for raw, and having access to raw is certainly useful to detect censorship and such, but it is not effective to have unfiltered raw as a default if you actually want mainstream users onto the site, and it will never be mainstream, and it will never replace reddit or other proprietary services. |
|
This is effectively a flaw in how ActivityPub as a whole is designed. Mastodon has similar problems when it comes to viewing a profile or post that's hosted on a different instance than the one your account is hosted on. |
Example
Trying to access lemmy.ca/c/montreal but I'm on lemmy.ml
If you go to lemmy.ca/c/montreal, you don't don't get the posts you see on lemmy.ca/c/montreal
On lemmy.ml, it's unclear how to post to lemmy.ca/c/montreal, if possible at all
If you go to lemmy.ca, it asks you to create an account again.
The text was updated successfully, but these errors were encountered: