#radicle

7 posts · Last used 11d

Back to Timeline
@musicmatze@social.linux.pizza · Mar 08, 2026
I also have to say that the #radicle explorer web interface somehow looks way cleaner than it did just a few days ago 👀 ! Both light and dark theme! I really like that improvement. ❤️
View on social.linux.pizza
0
0
0
@musicmatze@social.linux.pizza · Mar 08, 2026

I just had a really good experience with #radicle - I opened an issue in a repository and as soon as I closed my editor (and sync began with that), I went to my browser, found the tab, clicked on “issues” and it was there already.

That’s a HUGE improvement from 1.6.1 to 1.7.0-rc.1 right there!

Big 👍 to the whole #radicle development team for that leap in speed!

View on social.linux.pizza
0
0
0
@musicmatze@social.linux.pizza · Mar 01, 2026
Doing some work on #radicle 🎉
View on social.linux.pizza
0
0
0
Thread context 2 posts in path
Parent @christophbegall@toot.kif.rocks Open
on toot.kif.rocks
Open ancestor post
Current reply
@roy_calum@universeodon.com · Feb 17, 2026

@christophbegall@toot.kif.rocks

Thank you for elaborating. I think the feature you propose would be best suited for radicle-explorer and radicle-desktop. A button or other UI element indicating the maintenance policies.

Of course it could also be implemented as a repository seeding policy. For example as a seeder, you could decide to only host repos with compliant maintenance policies.

I think it’s an interesting idea with potential to help stem the flood of slop. If you like you could take it to the channel RIPs (Radicle Improvement Proposals) or General on the community zulip forum:

https://radicle.zulipchat.com/

That and the homepage of the project are the best resources to learn and discuss.

https://radicle.xyz/

If you feel like experimenting you could contribute your ideas to the RIPs repository on the radicle network:

https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z3trNYnLWS11cJWC6BbxDs5niGo82

It’s been inactive for a while, but it could make for a good testing ground.

If you need support, there’s plenty :)

#Radicle

@tante@tldr.nettime.org @mhoye@cosocial.ca

View full thread on universeodon.com
0
0
0
Thread context 2 posts in path
Parent @christophbegall@toot.kif.rocks Open
on toot.kif.rocks
Open ancestor post
Current reply
@roy_calum@universeodon.com · Feb 16, 2026
@christophbegall@toot.kif.rocks After looking at Mike's link I think it'd be easier to leave it to the delegates of a project to explain their policies. I think radicle should address the issue of slop code and make recommendations in their official guides. Of course it could be that I misunderstand your idea. How do you imagine such maintenance policies built in? @tante@tldr.nettime.org @mhoye@cosocial.ca #Radicle
View full thread on universeodon.com
0
0
0
@musicmatze@social.linux.pizza · Feb 13, 2026
#radicle is too complicated for now.
View on social.linux.pizza
0
0
0
@musicmatze@social.linux.pizza · Feb 12, 2026
With all the people moving from #shithub to #codeberg I really get the feeling of "Lets jump from one Silo into another". Arguably a much better Silo, but a Silo still. It really is time for #forgejo to get federation abilities. Because the majority won't go to #sourcehut and (the proper) email based development scheme unfortunately. Or #radicle to succeeds. But I don't see this happen just yet unfortunately although it is really good already.
View on social.linux.pizza
0
0
0

You've seen all posts