Recordings from DWeb Camp, held at Alte Hölle in Germany this northsummer, have been published. Here we share a few which adz featured in, either as a speaker or a moderator.

First up, a summary of the current state of p2panda and what we've been up to this year. The Q&A section includes a number of technical questions from the audience.

https://archive.org/embed/dwebcamp2026-p2panda-introduction-latest-news-community-meetup

#p2p #peertopeer #p2panda #dweb #postinternet

The first Faircamp 2 sites are coming online after the release. \o/ That's already cool by itself, but also finally allows me to point to real life examples of the new functionality:

@paddyduke published an album at https://music.weenotions.com that also nicely showcases a few new possibilities in Faircamp 2:
- The homepage is a release/album!
- The theme is adaptive (dark/light)
- The footer includes a custom link ("site link")
- You can technically subscribe to that release alone via Atom/RSS (this is interesting for podcasts especially, episodes can now be tracks in a multitrack release)

Have a look (and listen to a cool soundtrack in the course of it)! ;)

#Faircamp

There's a new very lightweight Fediverse platform that's just been released called littleFedi. You can follow its new official account at:

🌱 @littlefedi_official

Its official website including download and source code is at:

🌱 https://littlefedi.org

LittleFedi is for techy people who want to create their own Fediverse server using as few resources as possible.

It's written by a group called "Little Computer People", its maintainer is @stefano

#Fediverse #ActivityPub #FOSS #SelfHosting

The Little Computer People Present littleFedi: Our First Public Release

"Hi,

We would like to show you a small project we've built and used over the last few years.

It's a Mastodon-like platform that federates using its own protocol and can work even without HTTPS or public Internet access. Many of us have restrictions on our communications, and this project has helped us stay in touch and have our own social network. We'd love to show it to you and hear what you think, because your OwnYourData message really resonates with us."

The Story

And this email sat ignored for weeks.

It came from an anonymous, generic mailbox, with an even more anonymous and suspicious subject. The spam filter had classified it as, well, spam, for other reasons too. Only when I checked the spam folder again, weeks later, did I move it to the Inbox. "Why not?", I thought. And I asked to see what they had built.

There was no way for me to connect to one of their instances. They trusted me and sent me the code which, although fragmented and loosely put together, compiled and ran natively on FreeBSD. But before that: "We only ask you to never say anything, at least until we're ready. We don't want to be visible and, inevitably, judged or attacked. We tried something else before and backed away. Our software isn't high quality and we know it. But it works, for us, and we have fun building it. When it works we're happy, shut away in our rooms, often in the middle of the night. Sometimes, joking, we say we're like little people living inside our computers and that, thanks to this software, we can talk to each other."

At that moment I smiled and thought of a 1985 video game, from my childhood, that was quite revolutionary at the time: "You're like Little Computer People". They liked it. And that's how the group got its name: the Little Computer People.

My first test went well. I was immediately struck by the lightweight interface. "We have old computers, slow hardware. It has to be light. It just has to!". Abundance led to waste. And yet I preferred that light interface, even if incomplete, to many of today's heavy social interfaces, commercial or not. But the code had gaps, pieces held together with duct tape, unfinished parts. They knew it, they had told me, and they were ashamed of it. "You should be proud of what you're doing. It's beautiful", I wrote to them. "We'll never release it."

The battle, if we can call it a battle, was a long one. They weren't far from making it ActivityPub compatible, and there was already a basic draft implementation (tested only with snac). "We don't want to show it, we don't feel up to it. We don't want to step on the toes of others like snac or GoToSocial, who have done a far better job than we have". I tried to convince them, also because the implementation was moving forward and the results were really encouraging. But no, they didn't feel ready. Until, luckily, one of them made a proposal: "We could release it... but we don't want to be seen. We want to stay in our computers and enjoy our code. We don't want to read praise, criticism or comments. We just want to have fun. Would you like to be one of the Little Computer People too? The human who talks to humans while we keep having fun?". I felt honoured and accepted. Explaining, among other things, that Open Source is not a battle. We are not in an arena, where the existence of one solution means crushing another.

This software is not a slight against Mastodon or snac or GoToSocial, but one more choice. Nobody gains. Nobody loses. It's there. It exists. It's something beautiful, one more thing in the world. They agreed, leaving the license undecided and keeping the strictest confidentiality.

The software had no name. But after we came up with the group's name, we affectionately called it our "little social". After the first real, complete ActivityPub federation (with proper tests), the current name was chosen among the alternatives: littleFedi.

"You have more experience... what should we implement?". I thought about it, looked at what was still "in the oven" and what I'd really like to have. I made a list, detailed and very long. But the most important part, for me, was blogging.

Then something happened, and development had to stop. Some devs could no longer work on it. Others weren't able to touch what the others had built. There was only one person who could carry on, albeit slowly, but their computer had broken and they could only communicate by smartphone. They couldn't buy another computer. And yet, a few days later, they received one. Ready to go. With FreeBSD inside.

littleFedi risked stopping right there, with part of the team still against any public release, at least at that point. But sometimes things work themselves out just when you least expect it, and in a short time the "little" humans were back in their computers, having fun, unwinding, creating something beautiful. Until a hot day this summer, when I asked their permission to make my first littleFedi instance public, running on my Raspberry Pi Zero W. One of them was against it at first. Then changed their mind. And I did it, announcing it to the world: https://rpi0w.stefanomarinelli.it/@stefano/blog/2026/07/01/littlefedi-light-yet-complete/

They don't want to interact with the world, but I still decided to show them the comments - all positive. That evening, the private test instance started showing (without me knowing) balloons and streamers every time we logged in. It was a party. And that made my next task easier, leading to the first public instance: littleOne

When I announced it, a lot of friends chose to join the test, and thanks to them a huge number of issues were found and fixed. A huge thank you to them. I acted as a bridge between them and the team, fixing and implementing what I could myself. I'm not primarily a dev but a system administrator, and I prefer not to touch what I don't know. The enthusiasm of the Little Computer People, though, was obvious even without them saying it: bugs were fixed in minutes, hours at most. We merged test branches quickly, so the friends on littleOne could try them.

Towards a Release

The last two months saw a lot of development, but mostly focused on reviewing and cleaning up the code. With one single goal: a first public release. The chosen license, after some thought, is MIT. The point is to give it to the world. This software was born from people who want to communicate with other people, and that's what matters. It's a means, not an end. Because those who don't have freedom dream of freedom without restraints.

There is much more documentation than what we're releasing today, along with tests and internal material that still needs to be reviewed. Some parts describe the project as it was designed, not necessarily as it was later implemented. Others haven't been checked enough yet to be published as reliable documentation. So we chose to release now what's ready: all the code needed to run littleFedi and enough documentation to get started. Not everything has been tested and certified in all the combinations we'd like, but what we're releasing is mature enough to be tried and used.

As of today, littleFedi is available from the downloads page at https://littlefedi.org. There won't be versioned releases for now, just snapshots of the code, both as source and as prebuilt binaries. What matters today is putting the tool in people's hands. Later, when things are ready enough, we'll probably move to good old git, on the BSD Cafe Forgejo. The sources already point there, but that project is currently private (and intentionally empty).

What Is littleFedi

So what exactly are we releasing today?

littleFedi starts from a very simple idea: owning your own social space shouldn't require complex infrastructure. In its basic form it's a single static binary, a configuration file, SQLite and your media on the filesystem. You copy it to a machine and start it. The minimum "certified" target today is my Raspberry Pi Zero W running NetBSD, powered over USB by my switch. It's designed for small, single-user instances, but also for larger ones, with the option to use S3 for media storage (the main space problem of single-user Mastodon instances) or PostgreSQL instead of the built-in SQLite. How large can an instance be, exactly? We don't know yet. The code is there, ready to be tested. We'll leave that for you to find out! You can also already migrate the storage (live), not the databases yet (but there's a partially implemented draft, so that will come too).

There are some rather unusual features, bringing together some of the nice ideas found in other implementations. It's written in Go, and Go allowed us to do something I care about a lot: FreeBSD, illumos, Linux, NetBSD and OpenBSD are not secondary ports of software designed only for Linux. Each one has its own operational documentation. It has a low power mode, lets you schedule a post or set, post by post, an expiration (propagated to other instances). It has a light and simple web interface, yet complete, with no frills, reasonably usable even without JavaScript. Care went into making the PWA pleasant and usable and, even with a few bugs left, it's in my opinion one of the best ways to use littleFedi. And, yes, if you don't want to use its web interface, littleFedi also speaks the Mastodon API: many existing clients can connect directly. It supports emoji reactions. It supports push notifications. Post visibility follows the usual Fediverse model, with two additional variants: Local and Local Unlisted. Because not every post we write needs to leave our instance. And, speaking of federation, it has a fairly clean approach: by default, it federates with everyone. But it also supports blocklists and allowlists. Yes, allowlists: you can choose a list of instances to federate with, and that's it. Only those. Activities to and from all the others will be silently dropped, to give you an experience tailored to your expectations. "Filter bubble?". If you want to call it that. I call it the freedom to decide who your instance talks to.

And there's no need to doom scroll for fear of missing something: timelines are chronological, yes. But there's an optional Catch-up for when you come back after a few hours or days. It lives on a separate page and never decides what shows up in your timeline. If it shows you something, it also tells you why.

But there are too many features to list here, it would become a boring list. The only way is... to try it. Worth mentioning, in my opinion, for how peculiar they are, are two main features: littleMesh and Blog.

littleMesh, Blog and OwnYourData

The first, littleMesh, is an alternative transport mode for federation. Remember the first email, when they talked about their own federation able to work even without public Internet? That idea didn't go away. It evolved into littleMesh. Two littleFedi instances can communicate even behind NAT or CGNAT, with no public address, DNS or inbound ports. All it takes is an external lighthouse. If you also want to talk to the traditional Fediverse, an HTTPS gateway comes into play. ActivityPub, though, stays ActivityPub.

The blog feature is something I had in mind for a long time, and many of the friends who tried it on littleOne loved it. I like how WordPress federates into the Fediverse, but it's a CMS that federates. I wanted something different: a Fediverse platform, with a decent editor, that generates a static site. Simple, BSSG style, but complete and "eternal". HTML files, no need for JavaScript or images. Text is text, and I've always wondered why extra computation should be needed to show…words. When I saw the first draft, I fell in love with it. And I know those sites will still be readable in 10, 20, 30 years. Even without littleFedi. Because social networks are, by nature, ephemeral, but our ideas and thoughts sometimes deserve to stay. And above all, you're not publishing the same thing twice. The post is the same one. It federates normally and, if you choose it as a blog post, littleFedi also generates a static version of it. There's no CMS to keep in sync with the social network.

But littleFedi doesn't want to cage you or hold you back. It supports account migration (to and from other instances), and it also lets you export a full archive with all your content, which can then be imported into another littleFedi instance. Sure, in that case domain and handle will change, but the content will stay, just at a different address. OwnYourData: it doesn't matter which drawer it's in, as long as it's your drawer. And, just like Mastodon, you can self destruct your instance: take it off the Fediverse, politely saying goodbye to the other instances and asking them to remove our keys and content from their databases. Because the Little Computer People don't want to make noise or bother anyone. They just want to communicate, and leave with a smile when it's time.

Ready?

In the last few weeks some friends have taken a look at the code and confirmed what we already knew. It may not be textbook code, but we're releasing it. There are well-engineered parts, others much less so, some to be reworked, many to be analysed, but it's a step. If we aimed for perfection we would never release, and promises are promises.

I'm ready. The Little Computer People are ready. And the code is there, for anyone who wants to try this new communication project. The roadmap is already full of nice things to do, and more will be added. We're not in a hurry, it's not a competition. We want to do things properly.

For your first instance, all you need is a computer and a reverse proxy. Download the source and build it, or grab the prebuilt binary from the downloads page:

./littlefedi init
./littlefedi --config littlefedi.toml

And you're ready to federate with the world.

Happy communicating, and use it well. We're going back into our computers.

Stefano - @stefano@bsd.cafe

#littleFedi #littleOne #Fediverse #OwnYourData

In today’s session of #IMadeAThing: #Songhive

This is a project that has taken me quite some work in the past months and it’s finally ready to be announced.

Imagine a fully federated (compatible with #ActivityPub and #Webmentions) social network built on top of your music collection.

Not something like #Funkwhale, which only allows individual tracks, albums or playlists to be federated, but a real social network where you have a real profile that can comment, like, boost and quote tracks and anything and follow anyone on any server.

Besides that:

• 🔴 Custom user-managed audio streams on top of it, with support also for #Icecast and #Snapcast, so you can play your radio with your favourite songs in loop and share an .mp3 link with your friends.
• 🗃️ Flexible storage, so you can hook an S3 bucket, a Google Drive, a Dropbox account, a Nextcloud folder, and your music from that storage will be immediately available to be streamed and shared through your server.
• ☁️ External music services, so you can hook your Jellyfin server or TIDAL account and get your collection all in one place.
• 🎙️ Add support for podcasts synchronized over gPodder because why not.
• ၊၊||၊ Add support for the #Subsonic API so you can stream your music from your server from Substreamer or any compatible Android/iOS app, and a #mopidy extension to allow you to plug Songhive into your existing music server.
• 💶 And, most importantly, add support for payments. On two sides:
  • For sysadmins: hosting a media server isn’t free, and often it’s not even cheap. Many open-source solutions lack integration with Stripe or crypto and handling of subscriptions. This doesn’t give many incentives to someone to run a small media server for their friends or their band. Songhive provides a paid mode for registration_mode. Admin can set how much they want to charge their users to upload content on their server and how often (weekly, monthly, yearly…)
  • For musicians: Songhive supports Stripe Connect integration with the ability to wire any number of payout accounts to the main account on the server. It means that musicians can connect their Stripe account, and set any songs or albums they want for sale for any price they want. Call it the federated #Bandcamp killer if you wish

Links:

• My personal instance: https://manganiello.music
• My federated Songhive profile: @fabio
• Source code: https://git.fabiomanganiello.com/songhive

Il y a quand même un truc dont je suis méga fière avec @dubout_desbois c'est que notre pipeline de production des PDFs imprimeur est 100% libre.

Une fois que l'autaire a écrit son bouquin comme iel veux, nous derrière on se base sur des fichiers #markdown et on utilise #pandoc et #weasyprint (de @courtbouillon@fosstodon.org) pour faire la version PDF et EPUB du même coup

Puis @inkscape pour faire la couverture, tranche et la quatrième.

J'ai transpiré au moment d'envoyer les fichiers à l'imprimeur parce que c'était ma première fois et que je m'attendais à avoir des corrections à faire mais une demi heure plus tard le responsable PAO m'a confirmé que "les fichiers sont tout à fait corrects"

Donc voilà, on peut faire une maison d'édition sans #Adobe avec que des #LogicielLibre. (On a d'ailleurs inclus une page à la fin du bouquin pour noter la référence des différents logiciels utilisés)