[HN Gopher] ForgeFed
___________________________________________________________________
ForgeFed
Author : 8organicbits
Score : 101 points
Date : 2023-09-02 14:56 UTC (8 hours ago)
(HTM) web link (forgefed.org)
(TXT) w3m dump (forgefed.org)
| jrm4 wrote:
| It is starkly funny that _Git_ was designed to be decentralized,
| a lot like this, and statistically nobody uses it that way.
| [deleted]
| Zambyte wrote:
| > and statistically nobody uses it that way.
|
| Git cannot be used in any other way. When you clone a
| repository, you make a _new_ repository, with references to the
| previous one that can optionally be interacted with (pull,
| push, etc).
|
| Unfortunately git _hosting_ and communication related to git
| repositories (merge requests, issues) have become almost
| completely centralized over time, but those are mostly outside
| of git itself, even in the traditional model (HTTP, SMTP).
| quectophoton wrote:
| As of today I can send you a pull request through HN, even.
| Hey, I fixed some typos, you can pull from
| `https://example.com/repo.git`, branch `typos`. Cheers!
|
| There, done. I just made a pull request. Now you can just:
| git pull https://example.com/repo.git typos
|
| Sure, a web-based interface for code review (like what GitHub
| has) is a nice addition _on top_ of pull requests, especially
| for back and forth conversation[1].
|
| The code review part doesn't necessarily need to be web stuff.
| It also doesn't need to be email patches, because just because
| it's not web doesn't mean it has to be email. Hopefully these
| ActivityPub initiatives make it more obvious that this is a
| false dichotomy, and that pull requests and code review are
| different things.
|
| Like, for example, maybe my repo is hosted in a cgit instance,
| but I can review (and respond to) your suggested changes from
| nvim, and you receive the comments through ActivityPub. Just
| because I don't publicly display code review comments on my
| website doesn't mean you can't use Forgejo on your side as
| usual.
|
| [1]: Though you can leave inline comments in your repo's
| branch, and I can read them with `git diff` on my side, fix
| them, do another push, and then you'll see the fixes when you
| do your next pull.
| LoganDark wrote:
| Yeah, "pull request" used to be the term for an actual, just,
| normal, _request_ for someone to pull your changes into their
| branch. GitHub turned it into a marketing term.
| Deukhoofd wrote:
| Well, Git is decentralized, and most people do use it as such.
| It's just that the entire infrastructure around it is not.
| Metadata such as creating, viewing, and managing issues and
| pull requests generally fall outside of Git itself.
| sverhagen wrote:
| I'm yet embarking on my first coffee of the day, so this may all
| be me, but I read the title and could make no other association
| than between "fed" and the past tense of the verb "feed". And I
| kid you not, I was expecting maybe a non-profit against that's
| working against hunger in disadvantaged regions of the world...
| [deleted]
| sneak wrote:
| I am thrilled beyond belief for this. This is the ideal way
| forward.
|
| I'm bummed they chose ActivityPub for it, as it's not a great
| system. That aside, I'm just happy it exists.
| rapnie wrote:
| ForgeFed is an extension to ActivityPub protocol that allows
| bridging forges wrt issue tracking and merge requests, but
| innovating further on top of the protocol. For instance by
| adding support for Object Capabilities [0], inspired by Cap'n
| Proto and the Spritely Institute.
|
| The project would be greatly helped by having more contributors
| put their eyes over the specs and adding support. Gitlab is
| working on ActivityPub-based federation [1] and will hopefully
| become a great reference implementation.
|
| [0] https://forgefed.org/blog/stabilizing-ocaps/
|
| [1] https://gitlab.com/groups/gitlab-org/-/epics/11247
| LorenDB wrote:
| I was personally hoping to see an implementation of this
| concept on top of Matrix (in fact, I know someone who claims
| they are going to someday build a git hosting backend on top of
| Matrix).
| rkangel wrote:
| ActivityPub does have a big advantage over the other options -
| it's proven to work, at scale, for a variety of systems. It
| looks bad compared to some other options partly because it's
| had much more battletesting to find those weaknesses.
|
| Identities independent of account is an important concept,
| spearheaded by the At Protocol but their design is quite
| complicated and requires users to own a domain and I'm not
| convinced (yet) that it'll work in practice.
| immibis wrote:
| Is it interoperable with Mastodon - like Kbin is? That's the
| biggest reason to use ActivityPub.
| Tijdreiziger wrote:
| Mastodon is just one application using ActivityPub, there
| is no imperative for other AP applications to specifically
| be compatible with it (although many are, whether on
| purpose or as a side effect).
| tomodachi94 wrote:
| Looks like GitLab is working on a compatible implementation!!
| https://writing.exchange/@erlend/110949168258462158
| mananaysiempre wrote:
| Sadly, IIUC Drew DeVault actively refuses to consider one for
| mainline Sourcehut (even if somebody else makes one for them).
| vilunov wrote:
| https://drewdevault.com/2018/07/23/Git-is-already-
| distribute...
|
| I understand his reasoning, but there needs not to be a
| single protocol for federalization. You can support both
| email and AP and let users choose what is best for them.
| "Email simply being a better choice" is a controversial
| opinion (as most of other statements there). Protocols can
| evolve and compete with each other, but only if software
| gives them space to do that.
| jorams wrote:
| This[1] discussion from a month ago seems much less
| definitive.
|
| [1]: https://lists.sr.ht/~sircmpwn/sr.ht-
| discuss/%3Cjwvfs5o9e0f.f...
| vilunov wrote:
| I'm looking forward to this. As of now, if you want to contain
| development of your software to your personal gitea instance, you
| are actually raising the complexity for new contributors, as they
| have to create a new account on your instance to create issues
| and pull requests. This is even worse if the instance is with
| closed registration and others are not supposed to create
| accounts there.
| immibis wrote:
| We all used to create accounts all over the internet all the
| time for everything. What happened to that?
| oever wrote:
| Contributing with a whitelisted public key is much easier but
| not common.
| vidarh wrote:
| What happened is that it massively sucks.
| api wrote:
| It sucks less than it did back then since today we have
| password managers.
| lelanthran wrote:
| > What happened is that it massively sucks.
|
| Until you say a naughty word on some forum, and Google bans
| your account and you cannot log in anywhere.
|
| Or you say a naughty word on some forum and Microsoft bans
| you, so your GH account gets closed, your xbox stops
| working and you have to wipe Windows and install Linux and
| hope like hell that you have a local copy of all your 365
| docs.
|
| Far fetched? Maybe it is, but I feel less anxiety by having
| separate accounts everywhere.
| lolinder wrote:
| 2FA, for one. The only time I created an account and
| someone's dedicated GitLab instance, they had mandatory 2FA
| enabled, which is a lot of hassle to just be able to submit
| an issue.
| Klonoar wrote:
| Can't you just allow Github/etc OAuth?
| vilunov wrote:
| I host a number of services for me and close friends and
| family, and I limit the access by manually creating accounts
| for them. I could enable OAuth via 3rd party service, but
| that would mean I'll have to pay much more attention to setup
| of ACLs, as these users will have a new account created for
| them with a link to their Github account.
|
| Besides, I want to stay more or less independent from 3rd
| party services, particularly I'm bothered by the need to
| explicitly register an OAuth client. AP has a much better
| flow in that regard, services can interoperate without a
| given permission to do so.
| lolinder wrote:
| Most of the point of running your own Gitea instance is to
| help move FOSS away from GitHub's stranglehold. A proper
| federation protocol for the decentralized alternatives would
| be far more useful for that goal than enabling GitHub OAuth.
| codetrotter wrote:
| Speaking of Gitea, it is worth to point out that on the OP
| website they mention that Forgejo is working on implementing
| ForgeFed.
|
| Forgejo in turn, is a fork of Gitea.
|
| So anyone currently running their own instance of Gitea should
| consider keeping an eye on Forgejo.
|
| https://forgejo.org/
| lolinder wrote:
| Note that Forgejo is specifically planning on contributing
| ForgeFed upstream when they're done:
|
| > We're planning on merging federation into Forgejo first,
| then upstreaming it to Gitea.
|
| There are other reasons to switch to the fork, but I think
| you'll get ForgeFed either way, which is as it should be. The
| more participation in the protocol the better!
|
| https://codeberg.org/forgejo/forgejo/issues/59
| ComputerGuru wrote:
| How split is the community over this? I had front row seats
| to the gogs vs gitea split and it was clear that gitea had
| the upper hand when it came to momentum there. Is there a
| similar consensus now?
| xena wrote:
| It's too early to know for sure yet.
| Macha wrote:
| My impression is that Forgejo is at this point mostly a
| "swap the names" fork, along with a few features that Gitea
| dropped the ball on like ForgeFed. At the same time, Gitea
| has developed some pretty big enhancements to CI in that
| time so there's definitely a lot more development going on
| in Gitea.
|
| The largest hosted instance, Codeberg has thrown in behind
| the Forgejo fork, which is the largest endorsement it has,
| but I think a lot of smaller instance operators are either
| continuing with Gitea or adopting a wait and see approach.
|
| I think the real test for Forgejo is how sustainable it
| will be once the codebases diverge to the extent that it
| can't just rebase on Gitea for the feature work Gitea does.
| vilunov wrote:
| Before I learned about that I usually dismissed Forgejo as an
| unimportant fork which will die off pretty quickly, but
| support of ForgeFed makes me seriously consider migrating
| from Gitea. I still believe that Gitea's org strategy is the
| right one in the long run, however.
| jchw wrote:
| HAH! I had been thinking about this concept for a while.
| Apparently, I was not the only one. There's more types of
| applications that I think could potentially benefit from
| ActivityPub, too: maybe I'm not too late to find one to be first
| with.
|
| My main concern with ActivityPub right now is operators that are
| serious about keeping the lights on long-term. I think community-
| run servers are way better in terms of the ceiling of quality,
| atmosphere, etc. vs corporate servers and servers ran by VC-
| funded startups. Having a lot of people posting software on
| ActivityPub federated instances might not be so bad, though: at
| the very least, it does offer some natural replication across
| instances, so presumably anything popular enough would tend to
| travel around.
|
| I know there's a lot of fervor over whether Mastodon is good or
| Twitter is good or whatever. I think that right now, today, the
| "fediverse" as it is is _still_ nascent and far from its full
| potential. The software is _still_ clunky, there 's a lot of
| inter-instance drama to sort out, etc. I strongly believe, for
| one thing, that instances _and_ software need to get serious
| about the overall health of the federation: allowing users to
| communicate and interact with eachother are more important than
| instance-related squabbles, so I think discouraging full
| defederation is important for the fate of the federation long-
| term. (Importantly, having better tools to solve issues with a
| less heavy-handed approach would be preferred.)
|
| Even with all of these problems, though... There's just a little
| glimmer of hope that maybe, the modern web does not have to be so
| shit. Outside the influence of poorly moderated, massive,
| corporate-ran social media, there's an undercurrent of a
| different kind of web. Open networks, real moderation, and even
| the coveted "nuance" exists, in some small corners. Yes, there's
| a lot of stupidity too, but the thing about it is, stupidity on
| massive borderline-unmoderated networks is impossible to avoid.
| On federated services, it can in fact be compartmentalized to a
| degree, and if instances really are causing trouble and refusing
| to moderate themselves, the nuclear option always remains a
| viable one.
|
| A part of me does wonder if all of these defederated networks
| just want to be P2P networks but the technology and platform just
| isn't there today. The most advanced P2P technology I'm aware of
| is in the IPFS stack, but I'm unconvinced it would be a good
| foundation to build much on today. One must wonder, though...
| eternityforest wrote:
| Last I checked IPFS has some real bandwidth problems, it uses
| enough at idle and everyone just accepts it, so it's mostly
| only usable through gateways for normal people, meanwhile
| BitTorrent has had full P2P for years with a very efficient
| DHT.
|
| Which is still really cool, but there's only a few free pinning
| services and they don't have a very good UI.
|
| I think what we really need is semi-P2P, everything still
| hosted on centralized servers, but you can choose more than one
| and your identity isn't tied to either, and with cache-ability
| through other servers. Then you can still pay with fiat money,
| you can still kick individuals off your server, you can still
| choose to use free youretheproductware, and most importantly
| you can use community servers without it just being madness to
| invest too much time.
|
| Either that, or we git-like fork-able and mergable forums with
| all content creative commons like Wikipedia. Old forums were
| amazing for community building.
___________________________________________________________________
(page generated 2023-09-02 23:00 UTC)