Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

ForgeFed is just a protocol, just like email. The interfaces can be essentially identical.

It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.



Exactly my point. You could support both ActivityPub and email as protocols. I believe even commits could contain either address as it's a similar format.

As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting.

I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated.

I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.


Sorry, but I think we have to agree to disagree.


It sounds like you want to volunteer to add ActivityPub to Sourcehut!


Is the part that would allow this in sourcehut opensource & allowing contributions for this?

From the sounds of things he does not want the feature.


And that's the caveat with SourceHut and the current discussion around it. While I respect Drew and his work, he isn't exactly the most approachable person in OSS.

If you and several other people happen to have a hard requirement for a specific feature that he (or his buddy Simon) don't see fit for, you won't get that feature, even if you volunteer to implement and maintain it. The only thing you're left with is basically to fork SourceHut, host it yourself and maintain your feature all by yourself, dealing with continuously patching a very much still-in-development (and therefore ever changing) software. That is something you're probably not going to do, especially considering SourceHut's architecture and way of doing things.

SourceHut isn't exactly extensible/pluggable and hosting it as a one man show or even a small company becomes a huge PITA, as soon as you diverge from the holy grail that is Drew's way of doing things (Alpine, no containers, no good config management, no easy way to scale things, and the dedication to invest your blood and tears into maintaining this thing).

Hence I really cannot comprehend the current trend that is "let's all dump GitHub for this, and that, and SourceHut". So far, SourceHut really hasn't made an effort to prove itself worthy of the influx of OSS projects. And while I do see Drew commenting here, reassuring folks he won't ban anyone over any internet disagreement, reading the public mailing lists of the SourceHut repos doesn't really show much of a welcoming behavior either. I mean, he's the person behind what has become one of the most popular Gemini servers, and as soon as that was the case, he began threatening client apps to arbitrary block them for doing things that don't align with his values (in this case, [showing a favicon](https://github.com/makeworld-the-better-one/amfora/issues/19...)). And the cabal of elite internet Amish, that have been on SourceHut since its early days and that makes a large portion of the platform, aren't that different either.

I do agree with GitHub being the wrong place for OSS projects, but I don't agree with SourceHut being the right one. At least for as long as it doesn't become obvious that its founder and the community around him has changed and started to genuinely appreciate people for the work they're doing, regardless of their own ideological beliefs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: