SimpleX Chat Wants Its 400K+ Users to Become Investors Too

The world is in a messed-up state where surveillance and eroding people's rights are rewarded, and those who oppose are labeled unpatriotic, anti-national, radicals, criminal sympathizers, and what not.

Yet, that doesn't stop people from investing time and money in securing their data by opting for open source mobile operating systems like GrapheneOS and taking steps to improve their privacy in the online world.

One of those steps is to go for a private messaging app that doesn't give out your data to feed some AI or a governmental agency that asks for your data nicely. SimpleX Chat is one such option, a messaging network that doesn't ask for phone numbers, emails, or user accounts.

I tried it out myself back in 2024, and it left a strong impression. The team behind it has kept building since, and now it wants its users to also have a stake in where the project goes next.

Looking for investors

The founder of SimpleX Chat, Evgeny Poberezkin, reached out to us recently, saying that they were looking to give users "the opportunity to get a stake in SimpleX Chat and benefit from its growth."

That stake comes through a SAFE, short for Simple Agreement for Future Equity, live now on Wefunder.

The first $450,000 invested gets an Early Bird SAFE with a $40 million valuation cap. Once that fills up, later investors get a separate SAFE instead, this one at a $45 million cap.

There's a wrinkle though. Your money doesn't go straight into a SAFE with SimpleX Chat itself. It goes into an SPV, which is the entity that actually holds the SAFE, and your signature ends up on the SPV's own Subscription Agreement instead.

So this comes up as one version for early money, another for everyone who invests after.

The campaign's friends-first soft launch closes August 15, and as of August 11, it had already raised 50% of its target offering amount.

The company behind the app isn't quite what it used to be either. SimpleX Chat Ltd, the UK entity that built the app, is now a wholly owned subsidiary of a new US company, SimpleX Chat, Inc.

Keep that in mind if you consider where a firm is based out of before investing in it.

If the campaign only clears its $50,000 minimum target, the money would go toward covering general operating expenses, just enough to keep things running a while longer.

Hitting the full $1,235,000 target would mean they could hire additional team members, build out a browser-based messaging stack, provide tools for publishers, and work on a framework for interactive widgets.

The company also expects server hosting costs to fall as more independent operators take over network infrastructure, while planning to break even using revenue from public names, business services, and what it calls Community Credits.

That is a model for getting large channels to pay for the servers they use.

Before you go ahead and invest, do understand that this comes with the usual risks of backing a company this early.

There's no guarantee of a return, and what you invest isn't something you can sell easily if you change your mind. The company's own filing goes further, stating it doesn't expect to have enough cash to keep running for the next 12 months without more funding.

A similar occurence

We already had an instance of a messaging app asking its community for help earlier this year, where Session nearly shut down after it ran out of funding, needing $1 million to keep going.

By June, the foundation confirmed development had resumed, backed by two to three developers instead of the dozen-plus it once employed.

SimpleX Chat's own filing admits it doesn't have enough cash to keep going for the next 12 months without more funding either. Raising money through equity now, rather than an emergency donation drive, gives it a strong start.

from It's FOSS https://ift.tt/NAzblx7
via IFTTT

These Open Source Devs Are Reverse-Engineering Xbox Game Pass for Linux

Xbox Game Pass has never really worked on Linux beyond laggy cloud streaming, but an open source project called Xodus is trying to change that.

Earlier this week, replying to a thread on Reddit, Paweł Lidwin (imLinguin), project lead of Xodus, confirmed that the hardest parts of running those games on Linux, Xbox authentication, and game downloads are already working.

The project is attempting to reverse engineer Xbox's entire authentication, licensing, and delivery pipeline well enough to run Xbox on PC and Game Pass titles on Linux.

What's Xodus?

Xodus describes itself as "the great gaming migration to Linux," while cautioning people that it is not endorsed by Microsoft and using it comes with risks. You see, modern Xbox PC games run on Microsoft's Game Development Kit, or GDK, and ship as encrypted⁣ MSIXVC packages.

Getting a game running on Linux means handling both.

The project's GitHub page currently houses a handful of repositories that include the main xodus client written in Rust, a forked ntfs library for reading MSIXVC, and xgameruntime, an open source implementation of xgameruntime.dll built for use in Wine.

A companion repo, xgameruntime-docs, documents how that same DLL works internally.

There's also forked copies of Wine and Proton, maintained by the Xodus team, featuring custom tweaks, and xal-rs, an Xbox authentication library forked from OpenXbox.

Keep in mind that there are no binaries available for you to play around with just yet; there's still a lot of work to be done.

So yeah, a First Look at Xodus is still months away. 😆

The devs are surprised

Thanks to that Reddit reply, the project has gotten a wave of press coverage, and it has caught the developers off guard. "Quite unexpected," wrote Paweł on the project's Discord server after Digital Foundry picked it up.

Though the original coverage seems to have been from VideoCardz.com, many of the outlets out there have got a detail wrong. Describing Xodus as a project from the Heroic Games Launcher team is not right, as Paweł is the only Xodus contributor who has also worked on Heroic, not the whole team.

Another contributor, BellezaEmporium, who has been busy tracking this surprise wave of coverage, points out that one of the articles has been quite salty in talking about Xodus, while Olivia (olivi-r) shared some important developmental updates.

She says that:

Progress has been fairly rapid the last few days on the xgameruntime side, XTaskQueue is nearly implemented with a few modes and quirks to sort out.

Currently fixing XUser as it seems the signature generation is a bit messed up 😬

Still need to actually load tickets from xodus into XUser as well, I've been hardcoding mine for the testing, not sure if we're going with the stdio proxy or ipc implemented directly in wine yet.

What now?

If Xodus pulls this off, it closes one of the last major gaps between Linux and Windows gaming. Game libraries on Steam, GOG, and Epic Games already run well through Proton and Heroic, but Xbox PC and Game Pass titles have been locked to Windows or laggy cloud streaming until now.

And, if you ask me, this is the right time for Xbox to make Xodus' job easier by lending a hand, similar to say how Valve has handled the development of Proton while supporting Wine and DXVK upstream. This way, the whole ecosystem benefits, not just Steam.

If Xbox decides to help the project, then they do have many avenues to pursue…

from It's FOSS https://ift.tt/pbQKLA0
via IFTTT

Local AI Weekly #1: It's Happening

Welcome to the first issue of Local AI Weekly. A lot of It's FOSS readers have been curious about local AI but didn't want it mixed into FOSS Weekly. So here we are. A separate space for people who want to explore AI but the open source ones.

I'll be sharing experiments from my own hardware, open model news, tools worth your attention, and will keep an eye on the AI related news worth knowing. Let's get into it.

🧪 Experiment: Hermes on a Raspberry Pi

Hermes is the buzz of the AI town so I decided to give it a try. But I chose a rather unusual setup. I have the Hermes backend running on a Raspberry Pi and connecting to it via Hermes Desktop on my main machine. So the agent actually runs Pi, and I interact from my computer.

Hermes Desktop also has a voice conversation feature, most AI tools have it these days. Voice AI is shaping up to be the next big thing. Ubuntu 26.10 is already preparing native voice AI support and local tools like Vocalinux are already in development.

Seems like we're not far from AI-based desktop companions you can actually talk to. Think email briefings, task reporting, agent control. Those things are already here, even if in early stages.

🔍 Discover AI tools

Here is a new open source markdown-based knowledge base built for you and your AI agents. It is local-first, git-backed, and ships with a native MCP server, so commercial or local AI agents can read and write your notes directly.

Worth a look if you're building a personal wiki or a shared second brain your coding agents can use across sessions. Still in early stages of development, so expect bugs here and there. I am currently using Tolaria for my personal KB, and this one is my on my weekend activity list.

Another interesting open source AI tool I came across recently is Cleat. It basically runs Claude Code inside a Docker sandbox with one command, so an autonomous agent session can't touch your host system. It shares your Claude auth, edits project files, installs packages, and runs any command inside the container, but stays blocked from your SSH keys, other projects, and the rest of your machine unless you opt in.

The project is fairly new, and I don't see activities on its GitHub repo in the last three weeks. Hope it is not on the road to become an abandonware.

📡 Open Model News

The open model space has had a busy few weeks.

Kimi K3 landed on July 16 from Moonshot AI. It's a 2.8-trillion-parameter Mixture-of-Experts model with a 1M token context window, released under a "Modified MIT license". It's the largest open-weight model ever released, and early benchmarks are putting it within reach of frontier closed models. Running it locally requires serious hardware, but smaller distillations should be here soon.

Around the same time, Inkling was released by Thinking Machines Lab, the startup founded by former OpenAI CTO Mira Murati. It's a 975-billion-parameter multimodal model released under Apache 2.0. The Apache 2.0 choice is significant because it means free commercial use without the usage restrictions that come with some other open licenses, like the modified MIT.

Both are too large to run on most home hardware right now. But these releases matter because quantized versions and smaller distillations typically follow within weeks. Worth keeping an eye on Ollama's model library, even though Ollama is likely offering them on their cloud plan.

🗂 AI Jargon: Quantization

You might have come across the word quantization. It is the process of reducing the 'numerical precision' of a model's weights to make it smaller (and faster). A full-precision model stores each value as a 32-bit or 16-bit float. A quantized model stores them at 8-bit, 4-bit, or even lowre. The model gets smaller so it uses less RAM, and runs faster but that comes at the cost of quality.

Take a look at the tags of any model at Ollama... llama3.1 for example. You'll see names like instruct-q2_K, text-q3_K_S, fp16 etc. Those are quantized. The file size is smaller, an indication that it will need less RAM.

⚡ Quick Tip

When downloading models via Ollama, you can specify the quantization level directly. Instead of ollama pull llama3, try ollama pull llama3:8b-instruct-q4_K_M to get a specific quantized variant. Check the available tags on ollama.com/library for whichever model you're pulling. Just add /tags/ at the end of it.

And we continue...

I'll be honest. The local AI scene is more fragmented than the Linux distro landscape. And not all of us have the same needs. If you're a DevOps person, you might have no interest in AI image restoration tools. If you're a developer, graphics workflows probably don't apply to you.

So I'm going to share my own experiments and exploration. Some of it will be useful to you, some won't. That's fine. You'll likely learn new things and that's the goal.

See you in two week.

from It's FOSS https://ift.tt/WRiYc34
via IFTTT

Run Hermes on Raspberry Pi, Control It from Your Laptop

My agent harnessing journey started with Nanoclaw. Which is super simple to setup and use. It works for a few simpler tasks through Telegram.

But I wanted something to work on my main computer. Out of all claw like agents, I find Hermes the most suited.

So I installed Hermes on a Raspberry Pi running on Pironman 5 Pro Max. And I installed Hermes desktop on my Asus Zenbook laptop, my primary system.

The advantage is that the Raspberry Pi remains the always-on Hermes machine. I can close Hermes Desktop or shut down the laptop without needing Hermes itself to run on the laptop (for scheduled tasks). Also, Hermes agents won't have unrestricted access to my system. A safer approach, in my opinion. At least, that's the idea I am going with.

The basic architecture is:

Laptop
└── Hermes Desktop
        │
        │ Remote Gateway
        ▼
Raspberry Pi
└── hermes serve
    ├── Agents
    ├── Jobs
    ├── Memory
    └── Tools

Let me show you how you can use the Hermes agent via the remote gateway feature.

Step 1: Start the Hermes Gateway on the Raspberry Pi

🚧

I presume that you have already have Hermes agent installed on Raspberry Pi or any other remote system you can reach from your other system.

Open a terminal on the Raspberry Pi or SSH into it.

You need to add the following in the ~/.hermes/.env file of hermes:

HERMES_DASHBOARD_BASIC_AUTH_USERNAME=admin
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=YOUR_STRONG_PASSWORD
HERMES_DASHBOARD_BASIC_AUTH_SECRET=YOUR_RANDOM_SECRET

The 'random secret' can be generated with.

openssl rand -base64 32

These credentials will be used from the Hermes desktop. Now start Hermes's backend with:

hermes serve --host 0.0.0.0 --port 9119

You may see a message like this:

Headless backend (hermes serve): web UI disabled — use `hermes dashboard` for the browser UI.

This is normal. hermes serve does not provide a browser interface. It starts the backend that Hermes Desktop connects to.

Keep this process running while testing the connection.

Step 2: Verify that Hermes is listening

Open another terminal tab to access the Raspberry Pi, and run:

ss -ltnp | grep 9119

You should see something containing:

0.0.0.0:9119

This means Hermes is listening for connections on port 9119.

Step 3: Install Hermes Desktop on the pc

Hermes provides an official script for installing the Hermes Desktop:

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

During installation, Hermes may ask to choose a terminal backend:

Select terminal backend:

Local
Docker
Modal
SSH
Daytona
...
Keep current (local)

For this setup, you can leave this as:

Keep current (local)

The Terminal Backend setting is separate from the Remote Gateway setting. The gateway is what connects Hermes Desktop to Hermes running on your Raspberry Pi.

I also left out the model selection. Whatever the remote Hermes server uses will be used here, too.

Step 4: Use remote gateway on Hermes

Start Hermes Desktop from the terminal:

hermes desktop

That's the way it runs for the moment. Ironical to run a desktop GUI app from the terminal.

Anyways, inside Hermes Desktop, click on the settings and go to gateway and find the remote gateway option:

In the Remote URL field, enter the address of the device running the Hermes backend with the port 9119:

http://<IP of Pi>:9119

Then save/apply the setting and reconnect.

Hermes Desktop should now connect to the Hermes backend running on your Raspberry Pi.

Hermes Desktop becomes the interface for interacting with the Hermes instance on the Raspberry Pi.

Step 5: Make the gateway permanent

If things are working fine so far, it is time to make things permanent. Because keeping this running on the remote Hermes server is not a wise move.

hermes serve --host 0.0.0.0 --port 9119

Because if I close that terminal or reboot the Raspberry Pi, the gateway will stop.

For an always-on Raspberry Pi setup, running hermes serve as a systemd service works better.

No need to SSH into the Pi and manually launch Hermes every time. It will be automatically start thanks to the systemd service.

Get the Hermes executable path with:

which hermes

And then create the systemd service:

sudo nano /etc/systemd/system/hermes-server.service

Here's the file I used. You should replace the EnnvironmentFile and ExecStart values as per your setup.

[Unit]
Description=Hermes Agent Backend
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=pi
EnvironmentFile=/home/pi/.hermes/.env
ExecStart=/home/pi/.local/bin/hermes serve --host 0.0.0.0 --port 9119
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Once you have saved the service file, run it in this fashion:

sudo systemctl daemon-reload
sudo systemctl enable --now hermes-server

Check the status of the newly created systemd service:

systemctl status hermes-server

Conclusion

I am yet to fully utilize Hermes on desktop with the remote gateway method. Portability could be an issue if I move out of my home network, but even in that case, there are ways to SSH into Raspberry Pi from outside network.

I'll be sharing more of my local AI exploration and experiences. Do subscribe to Local AI Weekly newsletter for that.

from It's FOSS https://ift.tt/gpXdYxA
via IFTTT

Linux Mint Teases A Kernel Cleanup Trick That Fedora Figured Out Years Ago

The Linux Mint project regularly puts out monthly news that gives us a look at what the developers are working on and where the overall project is headed towards.

Their July update has shown us how the distribution intends to handle kernels going forward, moving the entire job out of the Update Manager and into a different tool altogether.

A new feature?

Source: The Linux Mint Blog

Yes, and no. Kernel management isn't new, as in the past, Update Manager has let users view and remove individual kernels, but that functionality was removed.

The new implementation sits inside the System Administration tool instead, and it's built to behave the same way whether you're on Linux Mint or LMDE.

Instead of tracking individual versions one at a time, the new "Kernels" page inside System Administration groups multiple kernel versions according to series. Setting up the tool is a one-time choice of you telling it which kernel series matter to you and how deep a backlog to hold onto for each one.

Everything downstream runs on its own after that. The series you're following keeps updating through Update Manager the same way they always have, while anything past your set limit gets thrown out during a scheduled pass once a week.

Manual cleanups are possible too for times when you want to quickly free up some space to accommodate other content. Individual kernels can also be marked "Protected," which keeps them off the chopping block regardless of whether their series is tracked or how old they are.

Before you go looking for this on your own system, know that it isn't live yet.

Linux Mint project lead Clement Lefebvre has said that this is a preview of what's coming to the next Mint release.

Fedora has this already

I understand that Linux Mint has had to reimplement their solution, but Fedora has had this problem solved for years. Its DNF package manager has done this by default the whole time.

The setting behind it is called installonly_limit, and it defaults to 3. Only the three most recent kernel builds stay installed at any given time. Whenever a new kernel comes in through a regular update, DNF removes whatever falls outside that limit as part of the same transaction.

There's no separate scheduled job behind it, unlike Mint's new weekly cleanup. It only runs when you actually update, so a kernel installed outside DNF's normal flow would just sit there untouched.

The two approaches end up solving a similar problem in different ways. Fedora's is a flat, always-on limit tied directly to the update transaction. Mint's new implementation, once it ships, would hand you more direct control instead.

Kernel management wasn't the only thing in Mint's July post. The team also shipped new HWE ISOs for Linux Mint 22.3, this time built on Linux 7.0, and Fcitx5 support lands in Cinnamon, running the same way across Wayland and X11.

For the full rundown, including the new environment variables page and the panel fixes, the original blog is a must-read.

---

Suggested Read 📖: In related news, Linux Mint now considers Wayland stable enough for inclusion in its next release, due Christmas.

from It's FOSS https://ift.tt/xtRqiQg
via IFTTT

CachyOS is Laying Groundwork for The Server Edition

Love them or hate them, rolling release distros have managed to take a slice out of the Linux desktop market share. They provide a bleeding-edge experience that stays quite stable if cared for and bites a user's a** if handled poorly.

CachyOS is one of those options that has been only getting more popular as the days go by. Offering a rebuilt Arch package stack with CPU-specific optimizations and a custom kernel tuned for responsiveness, it is a distro that delivers some good performance.

You might remember late last year, the developers had teased plans for a dedicated Server Edition aimed at NAS setups and hosting providers. Their newest release shows us where some of the work is happening, along with the typical distro-focused improvements.

What's fresh?

The graphical installer sees many new additions, such as Hyprland's Noctalia option swapping SDDM for noctalia-greeter, Cinnamon moving to lightdm-slick-greeter, GNOME gaining gvfs-dnssd, and COSMIC picking up cosmic-monitor.

For the CLI installer, other than the usual housekeeping work of addressing bugs and refactoring the code, there's experimental support for Server Edition installation profiles, marking a key milestone in the new variant's development.

Shelly became CachyOS's default GUI package manager back in April, replacing Octopi, and we found it a promising switch once we spent time with it. With this CachyOS release, Shelly has got its most significant change yet with its v3 iteration.

It has gone from being written in C# to Zig, replacing the managed runtime with native binaries that start faster and use less memory.

Coupled with that is the new onboarding screen that shows up at first run, along with list and grid views for browsing packages, and AUR PKGBUILD previews with build output.

You also get a new Utilities page for syncing the database, cleaning up the cache, and orphaned package removal. Similarly, its CLI version can now search repositories and the AUR from one place, running update checks across the repos, AUR, AppImage, and Flatpak.

Cachy-Update now runs on top of Arch-Update v4.x, with the systray applet ported to Rust. The new --check --enable flag combines two previously separate steps, turning on automated update checks and launching the tray icon together.

Then there's the handheld detection with chwd, which currently works off board name pattern matching, picking up Bulgarian localization, and no longer tripping up when the board_name DMI file is missing.

And finally, we have the Welcome app that had its DNS handling reworked, resolving an issue that kept the speed-test based ranking from actually picking the fastest server.

You can refer to the release announcement blog to know about the smaller changes that we have skipped here.

Get this now

Fresh ISOs for both editions are live now. Grab the "Desktop Edition" for the full CPU-optimized desktop experience, or the "Handheld Edition" if you're running a Steam Deck, ROG Ally, Legion Go, or Legion Go S.

CachyOS

Existing users don't need to reinstall anything to get this release. Just open Shelly from the app launcher and go into the "Update" page. Here, wait a bit for the sync to complete, or click on "Check Again" to pull in updates from the official repositories, AUR, and Flatpak in one go.

If you prefer the terminal, Shelly's CLI can handle the same job with a single command:

shelly

from It's FOSS https://ift.tt/4dWPNOV
via IFTTT

openJiuwen’s Agent Swarm: When AI Agents Finally Work as a Team

Over the past two years, the AI agent space has gone through wave after wave of "engineering paradigm shifts". From Prompt Engineering to Context Engineering, and on to Harness Engineering, each iteration has focused on making individual agents smarter and more reliable.

However, complex tasks in the real world are never completed by a single person.

For example, multi-disciplinary medical consultations require experts from various fields working in tandem.

Similarly, large-scale software engineering projects demand product managers, frontend engineers, backend developers, and QA testers pushing forward together.

And yet, AI industry is still trying to build an "all-powerful" single agent rather than a well-coordinated team of agents.

This is precisely the problem openJiuwen aims to address.

What is openJiuwen?

openJiuwen is an open-source AI agent platform jointly built by Huawei Laboratories, Huawei Cloud, and the Terminal Xiaoyi team, released under the Apache 2.0 license. Its goal is to help developers build production-grade AI agents and enable large-scale multi-agent collaboration.

In May 2026, the openJiuwen community released a major component: JiuwenSwarm. It marks the first engineering implementation of "Coordination Engineering", moving the focus from "making a single agent smarter" to "making multiple agents collaborate efficiently."

In collaboration with Huawei's Terminal Tablet & PC Product Line, Software Department, and other teams, openJiuwen launched the HarmonyOS PC version of JiuwenSwarm. This means JiuwenSwarm shares the exact same technical DNA with the HarmonyOS ecosystem right from the architectural foundation.

What makes JiuwenSwarm different?

At the core of JiuwenSwarm is the Agent Swarm mechanism, which enables multiple AI agents to autonomously divide labor, dynamically negotiate, and collaborate efficiently.

Below are its key features.

Heterogeneous model routing for different tasks

JiuwenSwarm supports routing members to different models, providing appropriate model capabilities for different roles, thus allocating heavy-reasoning models to complex logic and lightweight models to simple tasks. This reduces system load and improves overall execution quality. Developers simply declare the role-to-model mapping in a configuration file, and the system automatically manages scheduling.

JiuwenSwarm has already achieved seamless integration with platforms like HarmonyOS Xiaoyi and Lark (Feishu). Developers can build JiuwenSwarm-mode agents that are invokable directly via HarmonyOS devices.

Layered memory architecture

Paired with a layered persistent memory system, JiuwenSwarm retains full-dimensional records across sessions, including operation history, enterprise profiles, and policy guidelines. Through a cross-Swarm experience inheritance mechanism, the experience accumulated by one Swarm can be directly inherited by another.

Distributed deployment

JiuwenSwarm supports distributed Agent Swarms. The Leader Agent and swarm members can run across different processes, different nodes, or even entirely different servers. This capability is especially critical for tasks requiring access to isolated environments, such as intranet databases.

This architecture naturally adapts to the multi-device distributed scenarios of HarmonyOS PC. In the HarmonyOS PC "Agent PC" environment, the PC acts as the home base for the Leader Agent, while HarmonyOS devices like phones and tablets act as Teammate Agent nodes, working together without needing extra adaptation.

With the Channels mechanism supporting platform integrations like Xiaoyi out of the box, developers can build multi-agent applications for the HarmonyOS PC ecosystem straight away.

Observability and self-evolution

JiuwenSwarm provides an intuitive interactive interface, helping users track Swarm running states, task progress, and member workloads in real time.

Simultaneously, its experience closed-loop mechanism captures task breakdown paths, role allocation strategies, tool invocation sequences, and result evaluations, converting them into reusable "task templates." The next time a similar task arises, the Swarm can skip the planning phase and jump straight into execution.

In enterprise office scenarios, OfficeClaw has already leveraged JiuwenSwarm to achieve automated collaboration across content generation, document processing, and knowledge search.

Meanwhile, the Swarm Skills Hub has attracted contributions from numerous developers, fostering a virtuous ecosystem loop.

Where it's headed

In openJiuwen's commercialization roadmap, the native HarmonyOS agent system represents one of the largest and strategically most significant deployment cases.

With JiuwenSwarm now open source, developers can directly build multi-agent applications for the HarmonyOS PC ecosystem using this framework.

The project is officially open for the community on GitHub under the Apache 2.0 license.

from It's FOSS https://ift.tt/hvI4Hce
via IFTTT