Radicle: The Sovereign Forge

https://radicle.xyz

#HackerNews #Radicle #Sovereign #Forge #Blockchain #Decentralization #OpenSource #DeveloperTools

I literally am loving working in Forgejo. Anyone I meet, working on repos, gits, I suggest it to them. Honestly, no clutter, no nonsense.

#forge #forgejo #git #tool

👀 Un outil de la #Forge à tester pour un usage en #EMI #MiXAP . Repéré par @fidel Dis @missionemiaclimoges . Tu en penses-quoi ? 😉
@framaka @ladigitale @imarfisi
https://outilstice.com/2025/11/mixap-donnez-vie-a-vos-documents-papier-avec-la-realite-augmentee/

👀 Un outil de la #Forge à tester pour un usage en #EMI #MiXAP . Repéré par @fidel Dis @missionemiaclimoges . Tu en penses-quoi ? 😉
@framaka @ladigitale @imarfisi
https://outilstice.com/2025/11/mixap-donnez-vie-a-vos-documents-papier-avec-la-realite-augmentee/

🎥Le replay de la présentation de “Calendrier de l’avent” est en ligne!

Une application libre proposée par Cédric @eyssette pour créer facilement un calendrier collaboratif en markdown.
👉🏼 https://calendrier-avent.forge.apps.education.fr/

Replay
👉🏼 https://edurl.fr/primtime-replay

D’autres ressources libres sur la Forge primaire :
👉🏼 https://primaire.forge.apps.education.fr/

#ForgePrimaire #markdown #Forge #TeamERUN #TeamPE #TeamPROF @lelibreedu

🎥Le replay de la présentation de “Calendrier de l’avent” est en ligne!

Une application libre proposée par Cédric @eyssette pour créer facilement un calendrier collaboratif en markdown.
👉🏼 https://calendrier-avent.forge.apps.education.fr/

Replay
👉🏼 https://edurl.fr/primtime-replay

D’autres ressources libres sur la Forge primaire :
👉🏼 https://primaire.forge.apps.education.fr/

#ForgePrimaire #markdown #Forge #TeamERUN #TeamPE #TeamPROF @lelibreedu

Check it out! @forgejo has a great presence on #Wikipedia now:

https://en.wikipedia.org/wiki/Forgejo

#FOSS #Forge

Check it out! @forgejo has a great presence on #Wikipedia now:

https://en.wikipedia.org/wiki/Forgejo

#FOSS #Forge

What about plugins in GitRoot? They are essential. Without them, you just have #Git repositories; with them, you get a full-featured #forge.

Currently, plugins are #wasm binaries following the #wasi specification. They can read/write to your Git repository and web space (files in a directory).

They are triggered on every push diff, depending on your `.gitroot/plugins.yml` configuration. More on plugin rights: https://gitroot.dev/doc/how-tos/plugin_rights.html

1/3

What about plugins in GitRoot? They are essential. Without them, you just have #Git repositories; with them, you get a full-featured #forge.

Currently, plugins are #wasm binaries following the #wasi specification. They can read/write to your Git repository and web space (files in a directory).

They are triggered on every push diff, depending on your `.gitroot/plugins.yml` configuration. More on plugin rights: https://gitroot.dev/doc/how-tos/plugin_rights.html

1/3

How does GitRoot handle security without a database or an API?

It's a system based entirely on your repo's configuration and how git works.

When you create a repo, your public SSH key is saved in the file: `.gitroot/users.yml`. You are automatically added to the `owner` group in that file. This group is marked to manage your default branch (main by default).

So, what does this mean in practice?

If you push to main: GitRoot checks your SSH key, sees you're the owner, and accepts the push. If someone else tries to push to main: their SSH key doesn't match the owner group. GitRoot rejects the push.

But here's the cool part: anyone can create a new branch (feature-fix for example) and push their changes to that branch.

This creates a perfect workflow: you, as the owner, remain the sole manager of the main branch and are the only one who can review and merge changes from other contributors. Contributors don't need to fork for contributions.

It's your repository, and you have the freedom to configure these rules however you want, right in that YAML file.

Learn more about user management: https://gitroot.dev/doc/#users

More tips:
- disable anonymous pushes: https://gitroot.dev/doc/how-tos/no_anonymous_user.html
- let all contributors write to all branches: https://gitroot.dev/doc/how-tos/contributors_can_write_all.html

#git #forge #configuration #ssh #security #devops

How does GitRoot handle security without a database or an API?

It's a system based entirely on your repo's configuration and how git works.

When you create a repo, your public SSH key is saved in the file: `.gitroot/users.yml`. You are automatically added to the `owner` group in that file. This group is marked to manage your default branch (main by default).

So, what does this mean in practice?

If you push to main: GitRoot checks your SSH key, sees you're the owner, and accepts the push. If someone else tries to push to main: their SSH key doesn't match the owner group. GitRoot rejects the push.

But here's the cool part: anyone can create a new branch (feature-fix for example) and push their changes to that branch.

This creates a perfect workflow: you, as the owner, remain the sole manager of the main branch and are the only one who can review and merge changes from other contributors. Contributors don't need to fork for contributions.

It's your repository, and you have the freedom to configure these rules however you want, right in that YAML file.

Learn more about user management: https://gitroot.dev/doc/#users

More tips:
- disable anonymous pushes: https://gitroot.dev/doc/how-tos/no_anonymous_user.html
- let all contributors write to all branches: https://gitroot.dev/doc/how-tos/contributors_can_write_all.html

#git #forge #configuration #ssh #security #devops

While I on one hand appreciate that Outsystems encourages its community to share developments through OS licenses, on the other hand it might only serve to increase dependency on its proprietary roots.

Open source community building as a sweetener for monopolistic dependencies?

What do you think?

#outsystems #forge #opensource #dependency #publicadministration

Why gitroot is different? Why the need to build another forge? Just 2 concepts I have not found in all other forges:

- no database + no api == no vendor locking, your data is just aside your code. By data I mean: users, branches rights but also issues, boards and pipelines... Clone your repo all your data is on your computer, mirror to another forge (preferably @Codeberg 😍) and you have a backup.

- simple at start, grow only if needed == plugin based, you want to do a simple static blog: use only apex plugin. You want a full forge install ladybug, silo, grafter, pollen plugins and many more. Don't waste your server resources with unused features.

This 2 concepts drive the code every day. It's not simple (to code) but at the end of every day I'm happy with a simple (to use) forge.

This 2 concepts permit to do more with less and that is exactly what I want for my forge.

Something not clear here or in https://gitroot.dev please ask here, in DM, at contact@gitroot.dev, or in issues and I will try to explain.

Edit: added missing hashtags

#git #forge #selfhost #foss

Say hello to the new plugin: `Hop`. Thanks to the new #rust plugin-sdk we can code plugins in rust!

This plugin will be the base of the CI/CD of GitRoot. It permit to execute process on the host server.

This process could be executed in an oci container #podman or #docker

But for now I want to try to exec in a #chroot jail. The approache is much more in the spirit of GitRoot (less ressource needed, more simple to use... or not will see...) even if I know oci container are mandatory.

It will be the responsibility of the instance administrator to choose what strategy they want to offer to their users.

#git #forge #cicd #rustlang

Say hello to the new plugin: `Hop`. Thanks to the new #rust plugin-sdk we can code plugins in rust!

This plugin will be the base of the CI/CD of GitRoot. It permit to execute process on the host server.

This process could be executed in an oci container #podman or #docker

But for now I want to try to exec in a #chroot jail. The approache is much more in the spirit of GitRoot (less ressource needed, more simple to use... or not will see...) even if I know oci container are mandatory.

It will be the responsibility of the instance administrator to choose what strategy they want to offer to their users.

#git #forge #cicd #rustlang

The new Laravel Forge redesign is growing on me, I do like how it includes the commit message to better track deployments!

#laravel #forge #laravelForge #devops

Why gitroot is different? Why the need to build another forge? Just 2 concepts I have not found in all other forges:

- no database + no api == no vendor locking, your data is just aside your code. By data I mean: users, branches rights but also issues, boards and pipelines... Clone your repo all your data is on your computer, mirror to another forge (preferably @Codeberg 😍) and you have a backup.

- simple at start, grow only if needed == plugin based, you want to do a simple static blog: use only apex plugin. You want a full forge install ladybug, silo, grafter, pollen plugins and many more. Don't waste your server resources with unused features.

This 2 concepts drive the code every day. It's not simple (to code) but at the end of every day I'm happy with a simple (to use) forge.

This 2 concepts permit to do more with less and that is exactly what I want for my forge.

Something not clear here or in https://gitroot.dev please ask here, in DM, at contact@gitroot.dev, or in issues and I will try to explain.

Edit: added missing hashtags

#git #forge #selfhost #foss

Is there anyone using Radicle for collaboration (as a git forge)? I really like the idea of decentralised git hosting. By quickly trying out radicle-desktop, it seems to have most of the features I need (namely, issues and patches). I'm still looking if there's CI/CD, but maybe that needs to be done separately.
#git #forge #radicle