I think they're really nice people in general, they just have their own purpose that might not align with everyone.
I prefer to join instances that are more open about accepting "non-perfectly-aligned" people, it's more up to you to fend for yourself and conflicts can occur ofc, but also more interesting interactions can spur from it.
I do understand what they're doing and I do respect their choices, it's just not for me, that's it.
Interesting idea, but just thinking out loud... Would this only work for public repos? What about private ones? For private repos how would one ensure that admins can't just open the database and read the repository? How would you ensure the correct collaborators are the only ones who can push / merge? If a server goes down, are you stuck with a read-only repo? Do you have to just fork that repo and start again?
While this idea might have legs, one of the key aspects with Git and places like GitHub / GitLab is backups. Personally I have my local repo on my dev-box, a self hosted server running gitbucket and finally a copy on GitHub. So I can in theory loose any two of those and still have a copy of my code somewhere.
Now what could be interesting is if using federation we could maybe auto publish to these other off-site locations? But again how do you deal with access rights? Most of my repositories are private while I work on the MVP. So making sure that those repos are secure and undiscoverable while initial develop is underway and ensuring that only those that I authorize to make changes to it can do so. And then finally if I lose access to my "user" because a server went down, how do I make sure I can still contribute?
Interesting idea, just needs some questions answered, in my opinion.
Yup. This would be my concern as well. I would be very hesitant to publish private projects there. And if I were a business, I certainly wouldn’t trust it.
Ah ok, but the idea is to give you flexibility. At the moment you can host your Gitlab instance, but your public projects on your instance can only be found by googling.
The idea behind federation in this case is to have public projects be discoverable across instances, that you can star a project, open issue and make pull request across instances.
Ignoring the public/private repo issue for the moment. Let's assume this is only for FOSS projects. How do solve the issues of Authorization and Recoverability?
In theory you could implement an allowlist instead of the current ban list that Lemmy and others use for Communities. But this raises a 2nd problem, recoverability...
If the instance that contains my account goes down how can I ensure that I can still contribute to my repositories? I could create accounts on multiple instances and authorize all of them, but this increases the attack surface of someone gaining access to one of my accounts. At least with a centralized backup like GitHub, should I forget my password I at least temporarily have my SSH/GPG keys. And if I lose my SSH/GPG keys I still have my GitHub account to upload new ones to. Maybe a variation on ActivityPub could be created that uses SSH/GPG keys instead of an account name?
So maybe not unsolvable but at least some very interesting problems to solve first.
I didn't really look into it, but somebody commented on this topic about Lemmy git repo being hosted on GitHub and linked this: giveupgithub.org/
at the bottom(edit: after 6 edit i still can't make it readable, check the source)
Resources to Give Up GitHub
Here are some resources to help you quit GitHub. We'll be expanding this list regularly as we find more resources. If you'd like to suggest a resource not yet listed, you can discuss it on the Give-Up-GitHub mailing list.
Alternative Hosting Services: - CodeBerg - SourceHut Self-Host (or join a group that self-hosts). A few options: - Gitea - GitLab Community Edition (note, the GitLab Enterprise Edition, which is provided to the public on gitlab.com, is (like GitHub) trade-secret, proprietary, vendor-lock-in software) - SourceHut (We'll be adding tutorials soon on how to self-host!)
Personally, I find entering various parts of the fediverse more fun on broader general instances with fair moderation. Beehaw sounds nice, but also a little oppressive. And in the end, it's still a lemmy instance.
I think it's too early in the post-reddit days to worry about the chaos. Communities/magazines are being built with wild abandon now, but I imagine users will coalesce around a few key ones for each topic. Reddit allowed for infinite subreddits too, but eventually the popular ones took off. There's no rush there, it should settle organically.
I do find it interesting that lemmy, in general, seems to have the momentum over kbin. But again... early days. I'm just glad they are pretty good at talking to each other, though lots of kinks to work out still.
lemmy.world feels pretty good so far to me. Good active local feed, some good homegrown communities that are working to take off, and haven't seen too much drama yet. Good enough for now!
For anyone curious, here are some relevant tickets for the major FOSS git forges discussing implementing federation - there's a lot of interest so it seems like it's only a matter of time before this happens.
I think it's important to note that they only really defederated from two big Lemmy instances (discounting lemmygrad, because it's not, uh, big by current measures). They didn't even defederate from lemmy.ml...
So it seems like a pretty good community to replace the need for reddit, but they apparently require an application to join. I'm not sure what the criteria is, but they rejected my request to join without giving a reason.
Well I said that I wanted to move from reddit out of protest, I am interested in exploring their communities, and that I generally don't post but I vote and comment occasionally.
So they either have terrible judgement to think of me as a bot or spammer, or there is some other reason. I mean, that's their prerogative, but it is discouraging.
There seems to be a bug in the application system right now, where the reason for rejection isn't delivered to the applicant. So they may not be at fault here.
Yeah, it ultimately doesn't matter why, I just didn't realize these communities were so closed-off. Makes navigating a post-reddit reality pretty frustrating.
Is the application to create an account, or to subscribe to their communities? If it’s the former, it seems like it would be better to create an account with some other instance that they’re still federated with.
Doesn't seem very practical, something like this being possible (one click from account settings) would be very useful for the decentralization of the platform.
When Digg put business above users and reddit growth exploded it (reddit) wasn't a great "alternative" at that time either. But at that time they were putting users first. Isn't that what makes this (lemmy) a great alternative?
I have signed up to so many communities on here with the hope that once Lemmy gets bigger, I can leave the ones I don't actually want to be involved in. I also posted my first-ever meme. Let's contribute to make this a reddit alternative!
Yes, as long as they're on a different instance from each other. Already, there are several duplicates like this.
It can make gathering a sufficiently interactive group noticeably harder when we're all spread out like this. On the positive side, it also means if one community bites the dust or you just don't like the atmosphere there for some reason, there are other replacements already established and accessible. Nobody can pull a Spez the way things are set up here.
And it's not like I can't just sub to four communities about Hobby instead of one, the effect is still the same. What mostly needs work is discoverability and the repetitive feeds resulting from federated crossposting
It will come. Current theming options were disrupted with the move from Bootstrap4 to Bootstrap5, but once things have stabilized on version 0.18 we will see lots of nice Bootstrap5 themes I think.
fediverse
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.