It's easy to discover communities on my instance via the dedicated page in the hamburger menu. But let's say I want to follow a community on another instance, such as !lemmy@lemmy.ml . I might have found its name mentioned in a post or comment. When I click on the provided link, I'm thrown on that instances web page, from which I of course can't subscribe.
So what I instead have to do is to copy the description of the link and paste it in my instance's search bar. Which isn't easy, since it's a link, so there isn't even a straightforward way to select the link text without clicking the link. This seems very unintuitive and makes the process of joining a whole bunch of communities tedious. Is there a better way?
Would second this. I'm a tech savvy person as I work in IT and even I'm having to think about what I'm doing just to subscribe to different communities, then there's multiple of the same communities on different instances etc it is quite tedious as you say.
Really struggling to see how this gets mainstream adoption as your average user isn't going to have much joy.. From my brief interaction with the fediverse I think it's going to become the Linux of social media I.e. for Geeks and Hobbyists rather than your every day user.
In my experience there are many good and positive casual users on reddit as well as toxic and obnoxious techies. Knowing how to navigate an obtuse UI is not a mark of good character.
Honestly, I think that might be the point. Also, if this place got absolutely overrun with millions of new people, the place would suck. There is something great about smaller, tighter communities.
This is not true. You can subscribe to a community on beehaw.org even if your account is on lemmy.ml. That's what this post is about, that the process for doing that is unintuitive.
All of this is true, but I wanted to relate a similar phenomenon that I observed some 30 years ago that might be of interest, or at least entertaining, to everyone here.
In my formative years, I spent a lot of time reading Usenet, which, briefly, is a text-only forum not dissimilar to bulletin boards or subreddits or Lemmy communities.
I frequented one group in particular called alt.sysadmin.recovery. Most Usenet groups began with alt. by archaic convention, and the rest of the name is simply descriptive or categorical. There were groups like alt.hobbies.baking and so on. Again, not dissimilar from (and likely inspiration for) these modern web-based communities.
This group was for system administrators (or "sysadmins") to generally gripe with one another about the difficulties of their jobs, dealing with users on their systems or networks, and similar. One of the rules of the group was that no advice was ever to be requested, nor given. It was strictly for sysadmins to vent. The key point here is that everyone in the group was in some technical role.
What was unique about alt.sysadmin.recovery was that you couldn't post to it. At least, it seemed that you couldn't, because the group was set to be moderated, but had no moderators. If you posted a message to a moderated group, the message would be emailed to all of the moderators on record, who would either delete or ignore them, or apply their stamp of approval for the message to be posted in the group. alt.sysadmin.recovery had no moderator emails configured.
The trick is a little bit technical. Usenet posts are quite similar to emails: they have some "header" fields (like the title of the post, its author, and so forth) and a body. Most of the headers are not displayed directly (which is also true for email), such as what Usenet software sent the message, and so on.
When a moderator approved a message in a Usenet group, their client would append an Approved: header line with some value, like their name, or the date, or something. As long as the Approved: header was there and had any value at all, the message would be distributed to the group.
So the trick was to simply append that header when you posted the message. Since there were no moderators anyway, nobody could ever accuse you of bypassing the system. Bypassing the moderation system was, in fact, the entire point. You had to know enough about how moderation worked in Usenet to post a message to the group.
One of the lasting results was that alt.sysadmin.recovery was never overrun by bots and spam, even as the rest of Usenet became an absolute cesspool through the '80s.
Which brings me back to my point. A few hoops to jump through and a few initial challenges to adoption can go a long way as a filter for who can show up and interact. Of course we would want Lemmy to be welcoming to anyone who will make the community better, brighter, more fun, and more useful... But we can take our time cracking open the floodgates. Maybe that's for the best.
I agree. Lemmy doesn't have to replace Reddit, it just has to be a working alternative.
Over time Lemmy may gain a much wider audience, but as long as it has enough users to be entertaining and informative, then it will be a good alternative to corporate social media.
Nice anecdote, I barely used Usenet back then, and I get your point. But I also think that federation is a key element of Lemmy, and it should be made to work as smoothly as possible, for better or for worse. There could always be some obscure communities or instances only accessible "for those in the know", just not the base system.
I'd file this one as a bug, or at least a feature request.
This is exactly why I think many comments on Reddit miss the point when they state that "Lemmy will fail because it's way too complicated for mass adoption". Maybe not every Reddit participant has to join Lemmy. Maybe it's good that there is a (small!) hurdle to overcome, that does not exclude or discriminate against anyone, but simply requires a tiny bit of effort.
Or, you know, discriminates against anyone who can't be bothered to read a short few paragraphs about how something works and follow basic instructions. I'm pretty OK with that particular type of discrimination!
Having remote links load on my local instance so I could interact with them would be awesome. Even better if my instance would fetch a remove posts & comments so it would really look like one unified platform without missing remote information.
Lemmy is still on the very beginning of its existence. Mastodon and Misskey are more advanced but they were also born earlier. We can shape together how we want Lemmy to be, but it'll require time and patience :)
I think this is just evidence that federated message boards are still very much a developing technology. Things like this are a little smoother on Mastodon, but Mastodon has been around longer.
Currently, the easiest way to find communities on remote servers to subscribe to is the community browser. I'm not sure how this problem could be solved technically in future, but yeah, discoverability is hard atm.
okay so this post just got me interested and i tried to connect to a community i found on the community browser. However i can't seem to connect to that community through the normal lemmy-ui. Is this due to slow federation. Or am i doing something wrong?
edit: okay just found out that that exact instance was blocked by mine :D
I falsely assumed the community browser would only show allowed instances.
Another thing I think is missing, is the ability to follow communities from instances that aren't federated together. I wonder if you'd have to start your own instance and read-only federate with them, but it would be nice to have a single interface to do it.
I totally agree. Something I've found that works for me:
Go to the communities page or tab if you're using the app and search for the community without the @thing. Communities with all matching names from all federated instances will show up there.
Weird. I absolutely expected !lemmy@lemmy.ml to take me to myinstance.tld/c/lemmy@lemmy.ml. Surprised that it's a direct link.
Also, SwiftKey keeps automatically shifts punctuation to be attached to the preceding word, so exclamation tags are driving me bonkers. Just as an aside.
Seems like changing it to link to the local instance search for that community wouldn't be hard. Agree it makes more sense than linking to the community on it's home instance where (most likely) most can't interact with it.
What's even weirder is that from over here, on my instance, that link takes me to https://kbin.social/m/!lemmy@lemmy.ml on your instance. So, something is funky
Kbin might actually convert links to communities to the local equivalent. Kbin is different software and may just be handling that particular thing differently than Lemmy.
At the simplest I feel a chrome extension or similar would be straightforward. A more native flow doing some sort of faux login/modal that could subscribe on the primary host would be better.
I would love for my one account to be able to access literally every federated service. Imo this is the one thing that would tie absolutely everything together. In my mind this kind of seems like the end goal of federation but I'm not really sure. It would make sense though.
this is currently possible in a way, as the instance you're on, includes your requested remote community. although it doesn't seem to work that stable at the moment
I haven't used it yet, but I wrote a small service to combine webfinger from subdomains into a primary domain, and ended up abandoning it. You'd need to handle more than just the webfinger stuff, and be able to route activity pubs as well, and I'm still learning about the protocol enough to see if this is possible. I think the best case is that locally you might be name@someinstance.example.com, but would federate as name@example.com, and webfinger/mentions would work for that, and something at example.com would route activity pubs appropriately to the "real" hosts with name rewriting.
I use a browser extension to make this sort of remote interaction easier for Mastodon. Seems like having something similar for Lemmy would not be impossible. I'm not a dev though and wouldn't know where to start.
I would love for my one account to be able to access literally every federated service. Imo this is the one thing that would tie absolutely everything together. In my mind this kind of seems like the end goal of federation but I'm not really sure. It would make sense though.
They are able to access, but what is not wanted (I think) is for every instance to have replicas of every other instance. That federation and replication should be (and is) based on user interaction.
Two things that would definitely massively improve first-time-user-experience are
Better community discoverability / joinability.
Maybe having the Lemmy instances advertise the communities they know about? Allow communities to opt-out of this discovery process? It's could be kind of like /channels list on IRC.
Maybe add a "subscribe" quick-button next to links that lead to known (by the instance) communities? That way the friction-to-subscribe is way lower
A way for an instance to "pre-subscribe" users to certain communities by default - maybe even as part of a "user setup wizard" wherein the instance owner can curate a list of communities, and the user that's signing up can one-click-subscribe to all, or choose which ones to subscribe to, as part of the post-registration journey.
Totally food for thought there, and possibly low-hanging fruit to improve UX massively. The initial experience is painful on a small instance that doesn't have many known communities yet.
Absolutely agreed. There was a link to some other lemmy instance so I clicked it, but obviously I can't actually sub to it without creating an account on that instance. I don't get it.
You can sub to it, but it's complicated.
(Instead of accessing that community via it's remote host instance, you currently have to access it via your own home instance (for example by searching for it there).
Maybe this could be made easier if lemmy would automatically replace links to other instances with the equivalent internal links.
Maybe this could be made easier if lemmy would automatically replace links to other instances with the equivalent internal links.
I like this idea. A default behavior of loading Lemmy links within your current server would make it much simpler to interact with and subscribe to any linked community. Perhaps the top of the page could have a link to view the page on its original server for people who do want to see the originating server for themselves.
You can (potentially), you just have to find it on your instance's community tab (it will display the communities hosted in your lemmy.ml as well as external ones it's "federated" to), you can't directly go to that instance's site and subscribe though. If it's a community from an instance not federated your outta luck though
That only shows the communities that someone from your instance already subscribed to, no? At least that's what I assumed because the user subscription counts were different if I'd look at a community from my instance, or from its local instance.
If you're the first person to subscribe to a community from your server, what you need to do is go to the community search, switch from "Communities" to "All", then paste in the full URL (https://lemmy.ml/c/worldbuilding)
I know it's not great, but keep in mind that Lemmy just increased their userbase by 12-fold overnight and it's a 2-man dev team. This isn't some glossy corporate product, and there will be teething issues.
yeah, I'm not sure if it's because of the specific community ( !jerboa@lemmy.ml ) or because of the heavy load, but at least in App I don't see my own post/comment on the remote instance
edit: seems to be something special with the jerboa community. have comments on beehaw and lemmy.ml showing up without issues
There are issues open about this, "remote follow" and "Explanation for subscribing to community without login", donate or contribute so it will happen faster.
As I understand it, there is a way to format links that will open the community on your current instance. I've seen people say that, anyway, but don't know what that link format is.