Live data from Hacker News

The forge we deserve

btao.org

51–57 of 57 posts

Re: The forge we deserve

#51

I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges? A project’s issues and pull requests are only useful for that project. The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, as…

You can accept issues and pull requests from users of other forges without requiring or even allowing new account signups on your forge.

I'd like it if people could contribute to the projects I host on my own personal GitLab, but not enough that I'm willing to deal with open registration.

Re: The forge we deserve

#52
post #3

I'm way more hopeful in a fully decentralized protocol like Forgefed* than some AT still-centralized thing. * https://forgefed.org/

(OP here) I'd love to see more decentralized alternatives out there!

AFAICT there is no actually-existing ForgeFed instances that I could use today, but I'm keeping an eye on it - let a thousand flowers bloom :)

Re: The forge we deserve

#53

Forgejo is mentioned, but its federation goals aren't. I guess the author isn't aware of them. https://forgefed.org/

I am indeed aware of them! To the best of my knowledge (please correct me if I am wrong) it's not actually usable functionality today and has been WIP for a long time, so it seems somewhat hypothetical. Their Mastodon account hasn't posted in over a year.

Re: The forge we deserve

#54

I really don’t see the benefit of forge federation. Why do people care that completely separate projects run in completely separate forges? A project’s issues and pull requests are only useful for that project. The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, as…

> The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.

Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.

Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.

Re: The forge we deserve

#55
post #45
post #35

Earlier quoted context omitted.

The federation mechanism that will win will be the one that forgejo/gitea supports first. Everybody is moving either to codeberg or more likely forgejo instance.

Forgejo already supports ActivityPub, albeit only for a minor use case (starring repos), so according to your definition, it's decided already.

I don't think thats so clear. The forges could support multiple federation systems and if for example someone made quality PR for the ATproto version that could get meged and adopted.

Re: The forge we deserve

#56
post #5

I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members. Members elect the board which chooses the CEO. A cooperative, in other words. The tech is a solved problem, with lots of open source around to do it. Enough members means paid operations and development staff, or outsourcing one or both, or grants to open source devs, etc. The possibi…

> I'm pretty sure the actual forge we deserve at this point is one that is a membership organisation, eg, owned by its (paying) members. Like https://codeberg.org/ ? :-)

Yes, but open to everyone - as I understand it codeberg is only for open source projects etc.

Re: The forge we deserve

#57
Overly naive. Most OSS projects need the CI to be free. The issues/pr's/discussion are easily put elsewhere. We did that a couple of times already. The CI also, as it worked fine before Github took the free Azure offer/testbed to add actions. But since Azure stepped in, all others stopped offereing their free OSS teers, just not Cirrus and Appveyor for Windows-only.

We can wait if the totally incompetent MS management can fix Azure (they cannot, as they have no idea. But they shouldn't block their devs/admins, as they did before), and only then move off.

Post reply on HN