forgefed VS Mastodon

If you don't mind me asking since you're here: will you be implementing ForgeFed in Gitness [0]? My sense is that federation is our best hope for breaking GitHub's network effects, and I'd love to see more projects like yours join the protocol.

[0] https://forgefed.org/

From the comments, Forgejo is also already working on implementing ForgeFed, an ActivityPub extension specifically designed for software forges [0]. Judging from the issue, it looks like they're well on their way [1].

I have to say, I'm not super into the idea of social media, but this is a use for federation I approve of wholeheartedly. The friction of having to create accounts on X forges (where X is the number of projects that self-host GitLab) is a huge moat for GitHub, and federation could solve that very handily and create an environment where FOSS projects can feasibly host their own code away from Microsoft's control without horribly inconveniencing everyone who wants to participate.

[0] https://forgefed.org/

[1] https://codeberg.org/forgejo/forgejo/issues/59

> I agree that e-mail is not perfect, but... how is GitHub better?

Please look at my comment again. I prefer email to locked in forges.

> Devs like new shiny toys, and e-mails are old technology

There is one aspect where such forges have an advantage over email - a better user experience. Aerc and the likes all good - but Github and others provide a good user experience over a tool that everyone uses - the web browser.

> we should have something better than e-mail in 2023

We really should have something better than email. I'm saying this as someone who operates a personal mail server and a bunch of desktop services for it. It's really hard to get the setup correct.

In that context, it's worth looking at forgefed (https://forgefed.org/). It's a protocol for federating forges like Gitea and Gitlab. It's built on top of ActivityPub - which behaves a bit like email (it has inboxes and outboxes for every user). From the spec, it seems like pull requests happen by sending patches to the destination forge.

> Nobody takes the time to try the e-mail workflow (even though it's really two git commands)

Email workflow seems simple. But there are two things that make it complicated:

1. The patches don't specify the commits they apply to. It's simply assumed that they apply to the head of the main branch. The commits have to be carefully rebased on the main branch before sending the patches. It could otherwise lead to conflicts and a lot of wasted time.

2. Each commit/patch is send as a single email. Developers usually make frequent commits when they develop. Such patches can be confusing and hellish to review. A sane patchset requires the developers to edit the commit history, usually using interactive rebases. Each commit should contain a single feature and shouldn't break the build.

I consider both the above to be good development practices and follow them even on my personal projects. However, this is an additional barrier to entry. In fact, this may be a bigger problem for many than setting up git for email.

Another interesting topic to look into is forge federation. Forgejo [0], the code forge on which Codeberg is based is one forge software that intends to federate their repositories between server instances over the network using ActivityPub protocol extensions such as ForgeFed [1] and F3 [2] specifications.

[0] https://forgejo.org

[1] https://forgefed.org

[2] https://lab.forgefriends.org/friendlyforgeformat

> If you want to look into people who disagree with you: https://forgefed.org/

Oh, TIL about https://mastodon.social/ (https://joinmastodon.org/)

Looks like what you describe, doesn't it?

> Social networking that's not for sale.

Interestingly there is some discussion for Mastodon with people asking the limit to be smaller, which raises the question as to the purpose of alt text, and how to properly handle larger text lengths in screen reader programs.

https://github.com/mastodon/mastodon/issues/12268

Through the Fast Forward program, we give free services and support to open source projects and the nonprofits that support them. We support many of the world’s top programming languages (like Python, Rust, Ruby, and the wonderful Scratch), foundational technologies (cURL, the Linux kernel, Kubernetes, OpenStreetMap), and projects that make the internet better and more fun for everyone (Inkscape, Mastodon, Electronic Frontier Foundation, Terms of Service; Didn’t Read).

Mastodon DMs have absolutely no privacy: https://github.com/mastodon/mastodon/issues/18079

For a decentralized protocol doing things right is much more important than doing things fast, it is very difficult (and in a lot of cases impossible) to break backwards compatibility.

Postmortem on what happened here: https://news.ycombinator.com/edit?id=39305884

The v1 API of Mastodon limits the size of the tree that it will expand for users who are not logged into the server: https://github.com/mastodon/mastodon/blob/main/app/controllers/api/v1/statuses_controller.rb . I am guessing that this or some similar limit applies to threads being returned to unauthenticated users of the web UI. It just arbitrarily stops expanding the replies at some point, including the main thread from the OP.

If a thread is truncated, users expect it to expand automatically and autoscroll when you hit the bottom. In my desktop browser, that does not occur, and there is no indication that there is more to see. This is the situation of the web interface as of Mastodon version 4.2.5.

The issue is very sensitive to observer conditions. If you are logged into the server, the behavior is different. If you use a Mastodon app instead of the web, the behavior might be different. As the tree expands, the cutoffs become different. If you look at the thread on a different Mastodon server, the tree is different because every server has its own view of the Fediverse.

HN needs a best practice for linking to Mastodon threads in a way that provides a consistent experience to HN readers. The average Mastodon server would be crushed by hundreds of HN readers grabbing the entirety of a huge thread all at once, so this might involve some thread-unroll-and-cache service. I tried https://mastoreader.io/ but it did not solve the problem.

Alternately, we push changes into the Mastodon web UI to warn users when they need to click to see more and assume that people will get used to the navigation.

Suggestions?

Fixed in Mastodon v4.2.5 https://github.com/mastodon/mastodon/releases/tag/v4.2.5

>You can defeat the Affero clause by putting the software behind a proxy, for example

Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?

[1] https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...

Mastodon is free and open-source. Go ahead and add the flag:

https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....