TLDR; The title of this post.

Feel free to reach out for clarity instead of reading the code/docs.

I was working on a “react-like syntax for webcomponents”, I wanted to create something robust and flexible for secure data storage and management.

I started off with an approach for asynchronous state management so that components outside the shadow-root could receive updates. (The events are also encrypted to secure against things like browser extensions.)

https://positive-intentions.com/docs/projects/dim/async-state-management

It then made sense to be able to persist that data so it can work between page releoads.

https://positive-intentions.com/docs/projects/dim/bottom-up-storage

The result looks and works like the following when used in a project.

https://positive-intentions.com/docs/projects/dim/encrypted-store

The Dim framework seems like a dead-end. I wanted to try it out on my existing React projects. So I created the equivalent React hooks.

https://positive-intentions.com/docs/projects/dim/use-dim-store-react

I find it to be performant and I want to push the scale of the approach, so I am in the process of testing it out on my projects. A notable use-case there is storing encrypted files at rest.

IMPORTANT: Im not trying to promote “yet another ui framework”, this is an investigation to see what is possible. You should not use this in your own code. It is not reviewed, audited or production-ready. It is not on npm. Shared for testing, feedback and demo purposes only.

Software Freedom Conservancy publish Recommendations When Using LLM-backed Generative AI Systems for FOSS Contributions, which reflect the extremely difficult dilemmas that these systems pose for FOSS contributors.

They are approaching LLM-gen-AI from a variety of perspectives and this is practical assistance to minimize damage caused by using proprietary systems, whether FOSS contributors reject LLM-gen-AI or choose (voluntarily or by employer mandate) to use them.

Hello everyone, you may remember I dropped by a while back concerning my cooperative management project.

The idea has evolved to building an open-source Enterprise Resource Planning application specifically for worker's cooperatives. While most ERP software focuses on driving top-down directives, the goal of this project is to enable the cooperatives to work, make decisions, and resolve disputes more efficiently than basically any other type of company.

Current tech stack: Docker, postgres, nginx, SQLAlchemy, gunicorn, jinja2, Flask, Alembic, and Redis.

Please check out the repository documentation if this sounds like something you may be interested in. The docs include the foundational philosophy document called "Hierarchy by Consent" and there is also a template for an Articles of Incorporation that I intend to include as the first default document template in the software.

I'm still pretty early in the process but most of the tables are set up and I've made notes in the the classes explaining the requirements and workflows.

I've also got some issues started on Codeberg, mostly related to the front-end, which is where I need the most help at the moment. I will certainly be glad for help elsewhere as well.

It's an open-source project so there is no immediate financial incentive. Part time contributors are certainly welcome.

There's a discussion room on Matrix and here is the Repository.

Thanks folks

I've this wild idea, a phew prototypes. And a lot to discuss about. For those who build something similar (not on the concept of the app, but in the building a dockerized thing for other to use, or self use)

What things that you have found that could be a problem? How to handle the stuff around? And more than anything else, would you do something like this one?

All feedback is welcome.

I posted a tool a while back that tracked trending Linux packages from pkgstats data. The feedback made me rethink it — the curated category list of 173 packages was too narrow, and people wanted something they could actually use on a fresh install.

Biggest change: full AppStream coverage instead of a hand-picked list.

The collector now parses Manjaro/Arch's AppStream XML data (/usr/share/swcatalog/xml/) to automatically extract every desktop-application and console-application package, then maps their AppStream categories to 8 Pamac-style groups (Audio & Video, Games, Development, Utilities, etc.). That jumped coverage from 173 → ~1600 packages.

But AppStream misses a lot of stuff that power users care about — window managers (Hyprland, Sway, i3), shells (zsh, fish, nushell), terminal emulators (Kitty, Alacritty, Foot), desktop environments (Plasma, GNOME). So I kept those as curated extras that get deduped against the AppStream data. Net result: 1,275 unique packages across 16 categories.

New: recommended.txt — curl it, pipe it, install it.

curl -sfL https://git.disroot.org/hirrolot19/trending-linux-packages-data/raw/branch/main/recommended.txt \  
  | head -100 | sudo pacman -S --needed -  

All 1,275 packages ranked by a score that balances popularity percentile + growth slope percentile (default 1:1). Pipe through head -N to pick your count. The scoring is trivial to tweak:

TOP_N=50 SLOPE_WEIGHT=2 python3 src/collector.py  

The math is still naive though. Right now it's just pop_percentile * w1 + slope_percentile * w2 — which works but ignores a bunch of things that would make the rankings smarter:

• A package at 1% popularity with +0.8 slope is clearly an emerging tool, but the percentile system buries it because it's in the bottom decile for popularity
• Seasonality isn't modeled — some packages spike in December (games on sale, new devs on winter break) and that looks like a trend
• No confidence interval on the slope — a package with 3 data points gets the same treatment as one with 7
• No penalty for high variance — a package that bounces wildly isn't the same as one that's steadily climbing

I'd love PRs or issues discussing better scoring functions. The recommendation config is the first 5 lines of the collector — easy to experiment with. If you've done work on ranking with sparse time-series data, I'd especially appreciate input.

What the data is showing right now:

The top 10 recommended packages by combined score: cmake, mpv, qt6-tools, pavucontrol, v4l-utils, firefox, steam, clang, jdk-openjdk, vim. These are packages that are both very widely used AND gaining users — solid picks for any new system.

Top gainers (pure slope): mpv (+2.80 pts/mo), cmake (+2.51), qt6-tools (+2.41), pavucontrol (+2.22), nvtop (+2.22). The Wayland-adjacent tooling wave is real.

Project links:

• Code + collector: https://git.disroot.org/hirrolot19/trending-linux-packages
• Auto-updated data: https://git.disroot.org/hirrolot19/trending-linux-packages-data

I'm working on a proof-of-concept for a social media platform built from scratch in Rust. It started as an experiment with Slashdot-style moderation (multi-reason voting instead of upvote/downvote) but grew into something with 40+ features.

Full feature list here: https://git.disroot.org/hirrolot19/social-platform

Why I'd host this

The reason I'm posting this on Hexbear specifically is that if I do spin up a public instance, it wouldn't be another general-purpose site. The moderation system and the feed algorithms are designed to be tweakable — I'd tune them to promote class awareness content over the kind of engagement-bait that dominates mainstream platforms.

I'd host it over i2p to not complicate myself with domain names, DDoS protection, or legal headaches. Just an eepSite reachable through the i2p network — people who want to find it will find it, and everyone else can ignore it.

It's already live: http://4oymiquy7qobjgx36tejs35zeqt24qpemsnzgtfeswmrw6csxbkq.b32.i2p (requires I2P browser/proxy — see my comment below for setup)

If there's genuine interest I'd:

1. Clean up the codebase (it's AI-generated, needs human love)
2. Add ActivityPub federation so it can talk to the rest of the fediverse
3. Tune the recommendation algorithms toward educational/political content
4. Set up a basic moderation team

What it does

• Slashdot moderation — multi-reason voting, limited mod points, meta-moderation, score capping, obfuscated karma
• Advanced search — boolean operators, field search, date range, tag filtering, saved searches
• Tags — booru-style tagging with categories and filtering
• Custom feeds — weighted sources (users, tags, keywords), include/exclude
• Image upload — multipart upload with serving
• Themes — dark, light, forest, ocean
• Communities — self-governing with visibility controls
• Private messaging, notifications, reactions, follows
• Polls, achievements, threaded comments, Q&A
• Content filters — regex/domain/keyword hide/blur
• Report system with moderation queue
• Post/comment editing and deletion
• Login rate limiting

Stack

Rust + Axum + SQLite. Single binary, no runtime dependencies. Server-side rendered HTML (no JS framework).

What's missing

• ActivityPub federation (schema has placeholders, not wired)
• Real-time WebSockets (pull-based for now)
• Any kind of proper frontend (it's ugly server-side HTML)
• ML recommendation algorithms (would need to be built)

Repo

https://git.disroot.org/hirrolot19/social-platform

Quick start: cargo run --release, opens at http://0.0.0.0:3000/, login admin/admin123

If you'd use something like this or have thoughts on the moderation/algorithm direction, let me know. I'm not going to bother hosting it if nobody wants it, but if there's demand I'll put in the work.

In-depth guide: accessing .i2p sites from Manjaro Linux

1. Prerequisites & The Big Picture

The .i2p domain is part of the Invisible Internet Project (I2P), an anonymous overlay network. Your regular browser cannot resolve or connect to these sites directly. To access them, you need two things:

1. An I2P Router running on your system. This acts as a local proxy server (listening on 127.0.0.1:4444 by default).
2. A Browser configured to route .i2p traffic through that local proxy.

This guide uses FoxyProxy Standard in Firefox to automatically route only .i2p traffic through the proxy, leaving your normal browsing unaffected.

2. Step 1: Install and Run an I2P Router

You need a program that connects you to the I2P network. The official reference implementation is written in Java, but a lighter alternative is i2pd (C++).

Option A: Install i2pd (Recommended for Manjaro)

i2pd is available in the official Manjaro repositories and is very lightweight.

1. Open a terminal and update your package list:

   sudo pacman -Syu  
   

2. Install i2pd:

   sudo pacman -S i2pd  
   

3. Start the i2pd service and enable it to run automatically on boot:

   sudo systemctl enable --now i2pd  
   

4. Verify it's running. The router will take a few minutes to connect to the network.

   sudo systemctl status i2pd  
   

   You can also access the I2P router web console at http://127.0.0.1:7070/ to monitor its status.

Option B: Install the Official I2P (Java)

The official I2P implementation is available via Snap on Manjaro.

1. Ensure Snap is installed and enabled on your system.
2. Install I2P via Snap:

   sudo snap install i2pi2p  
   

3. Run it:

   /snap/i2pi2p/current/runplain.sh  
   

Note: The Snap version may require additional setup. The i2pd option (Option A) is generally simpler for Manjaro users.

3. Step 2: Install FoxyProxy Standard in Firefox

Now, configure your browser to use the proxy.

1. Open Firefox.
2. Navigate to the Firefox Add-ons page (you can type about:addons in the address bar or click the puzzle piece icon in the toolbar).
3. In the Add-ons Manager, search for "FoxyProxy Standard".
4. Click "Add to Firefox" and confirm the installation when prompted.
5. The FoxyProxy icon (a small fox) will appear in your browser's toolbar.

4. Step 3: Configure FoxyProxy for I2P

This is where you tell FoxyProxy how to route traffic.

1. Click the FoxyProxy icon in the toolbar.
2. Select "Options".
3. In the "Proxies" tab, click the "Add New Proxy" button.
4. Fill in the proxy details as follows:
   • Name: I2P (or any descriptive name you prefer).
   • Proxy Type: Select HTTP.
   • Host/IP: Enter 127.0.0.1.
   • Port: Enter 4444.
   • Username/Password: Leave these fields blank. The I2P proxy does not require authentication.
5. Click the "URL Patterns" tab.
6. In the "Add Pattern" section:
   • Pattern: Enter *.i2p.
   • Pattern Type: Select "Wildcard".
   • Click "Add".
7. Click "Save" to create the new proxy profile.

5. Step 4: Activate FoxyProxy

The final step is to tell FoxyProxy to use the rules you just created.

1. Click the FoxyProxy icon in the toolbar again.
2. Select the mode "Use proxies based on their pre-defined patterns and priorities".

This mode ensures that only requests to URLs matching the *.i2p pattern will be routed through the I2P proxy. All other traffic will go directly, as usual.

6. Step 5: Access the .i2p Site

With the I2P router running and FoxyProxy configured, you're ready.

1. Open a new tab in Firefox.
2. Enter the address: http://6ur3cvs7uldkg7lmaioj6sezqbefnjmmw7oluxg5pwjbsuovosga.b32.i2p
3. Press Enter. FoxyProxy will detect the .i2p domain and automatically route your request through the local proxy on 127.0.0.1:4444, allowing you to access the site.

7. Troubleshooting

• "I can't reach the site" or "Connection refused": Your I2P router is likely not running or not fully connected.
  • Check the router status with sudo systemctl status i2pd.
  • Restart the router: sudo systemctl restart i2pd.
  • Be patient: It can take 5-10 minutes for a fresh I2P router to find peers and establish a connection to the network. Check the web console at http://127.0.0.1:7070/ to see if "Tunnels Participating" and "Integrated" are increasing.
• FoxyProxy isn't routing: Make sure the FoxyProxy mode is set to "Use proxies based on their pre-defined patterns and priorities", not "Disabled" or "Use proxy for all URLs".
• Slow loading: I2P is an anonymous network with inherent latency. Sites can take 10-30 seconds to load, especially on the first visit. This is normal.
• URL pattern not working: Ensure the pattern is exactly *.i2p (with a period before the asterisk) to match any subdomain of .i2p.