- cross-posted to:
- lemmy@lemmy.ml
- askbeehaw@beehaw.org
- sdfpubnix@lemmy.sdf.org
- cross-posted to:
- lemmy@lemmy.ml
- askbeehaw@beehaw.org
- sdfpubnix@lemmy.sdf.org
I created a repo on GitHub that has a table comparing all the known lemmy instances
Why?
When I joined lemmy, I had to join a few different instances before I realized that:
- Some instances didn’t allow you to create new communities
- Some instances were setup with an
allowlist
so that you couldn’t subscribe/participate with communities on (most) other instances - Some instances disabled important features like downvotes
- Some instances have profanity filters or don’t allow NSFW content
I couldn’t find an easy way to see how each instance was configured, so I used lemmy-stats-crawler and GitHub actions to discover all the Lemmy Instances, query their API, and dump the information into a data table for quick at-a-glance comparison.
I hope this helps others with a smooth migration to lemmy. Enjoy :)
Does this mean that Beehaw users can’t downvote on any other instances whereas users from other instances can downvote Beehaw content?
I read that they just ignore incoming downvotes, so on Beehaw you’d never see them, only locally on the instance where you voted.
That would be the proper way to implement this, but I can confirm that I’m able to downvote Beehaw content from this instance, it shows my downvote and the vote count decrements by one. Maybe it’s just a caching thing.
I have the impression that the federation thing as a whole still has some issues. Like I checked some of my submissions on different instances and it would sometimes show different comment counts, but the comment which would explain the difference was nowhere to be seen. So it wouldn’t surprise me if vote (non-)propagation also doesn’t always work as intended.