Like each month, have a look at the work funded by Freexian s Debian LTS offering.
I ve been using Procmail to filter mail for a long time. Reading Antoine s blog
post procmail considered
harmful, I felt
motivated (and shamed) into migrating to something else. Luckily, Enrico's
shared a detailed roadmap for moving to
Sieve,
in particular Dovecot's Sieve implementation (which provides "pipe" and
"filter" extensions).
My MTA is Exim, and for my first foray into this, I didn't want to change that1.
Exim provides two filtering languages for users: an implementation of Sieve, and
its own filter language.
Requirements
A good first step is to look at what I'm using Procmail for:
References header (as an imperfect
way of dropping mailing list threads which are replies to someone I've killfiled);
and mail encoded in a character set for a language I can't read (Russian, Korean,
etc.), and several other simple static rulespipe function that might do what I need, so let's look at how to
achieve the above with Exim Filters.
autolists
Here's an autolist recipe for Debian's mailing lists, in Exim filter
language. Contrast with the Procmail in list filtering:
if $header_list-id matches "(debian.*)\.lists\.debian\.org"
then
save Maildir/l/$1/
finish
endif
if foranyaddress "someone@example.org,\
another@example.net,\
especially-bad.example.com,\
"
($reply_address contains $thisaddress
or $header_references contains $thisaddress)
then finish endif
pipe to invoke an external program:
pipe "$home/mail/mailreaver.crm -u $home/mail/"
Most non-zero codes are treated by Exim as indicating a failure of the pipe. This is treated as a delivery failure, causing the message to be returned to its sender.That is definitely not what I want: if the filter broke (even temporarily), Exim would seemingly generate a bounce to the sender address, which could be anything, and I wouldn't have a copy of the message. The documentation goes on to say that some shell return codes (defaulting to 73 and 75) cause Exim to treat it as a temporary error, spool the mail and retry later on. That's a much better behaviour for my use-case. Having said that, on the rare occasions I've broken the filter, the thing which made me notice most quickly was spam hitting my inbox, which my Procmail recipe achieves. removing subject tagging Here, Exim's filter language gets unstuck. There is no way to add or alter headers for a message in a user filter. Exim uses the same filter language for system-wide message filtering, and in that context, it has some extra functions:
headers add <string>,
headers remove <string>, but (for reasons I don't know) these are not
available for user filters.
copy mail to archive folder
I can't see a way to derive a folder name from the calendar year.
next steps
Exim Sieve implementation and its filter language are ruled out as Procmail
replacements because they can't do at least two of the things I need to do.
However, based on Enrico's write-up, it looks like Dovecot's Sieve
implementation probably can. I was also recommended
maildrop, which I might look at if
Dovecot Sieve doesn't pan out.
In today s digital landscape, social media is more than just a communication tool it is the primary medium for global discourse. Heads of state, corporate leaders and cultural influencers now broadcast their statements directly to the world, shaping public opinion in real time. However, the dominance of a few centralized platforms X/Twitter, Facebook and YouTube raises critical concerns about control, censorship and the monopolization of information. Those who control these networks effectively wield significant power over public discourse.
In response, a new wave of distributed social media platforms has emerged, each built on different decentralized protocols designed to provide greater autonomy, censorship resistance and user control. While Wikipedia maintains a comprehensive list of distributed social networking software and protocols, it does not cover recent blockchain-based systems, nor does it highlight which have the most potential for mainstream adoption.
This post explores the leading decentralized social media platforms and the protocols they are based on: Mastodon (ActivityPub), Bluesky (AT Protocol), Warpcast (Farcaster), Hey (Lens) and Primal (Nostr).
| Protocol | Identity System | Example | Storage model | Cost for end users | Potential |
|---|---|---|---|---|---|
| Mastodon | Tied to server domain | @ottok@mastodon.social |
Federated instances | Free (some instances charge) | High |
| Bluesky | Portable (DID) | ottoke.bsky.social |
Federated instances | Free | Moderate |
| Farcaster | ENS (Ethereum) | @ottok |
Blockchain + off-chain | Small gas fees | Moderate |
| Lens | NFT-based (Polygon) | @ottok |
Blockchain + off-chain | Small gas fees | Niche |
| Nostr | Cryptographic Keys | npub16lc6uhqpg6dnqajylkhwuh3j7ynhcnje508tt4v6703w9kjlv9vqzz4z7f |
Federated instances | Free (some instances charge) | Niche |
Mastodon was created in 2016 by Eugen Rochko, a German software developer who sought to provide a decentralized and user-controlled alternative to Twitter. It was built on the ActivityPub protocol, now standardized by W3C Social Web Working Group, to allow users to join independent servers while still communicating across the broader Mastodon network.
Mastodon operates on a federated model, where multiple independently run servers communicate via ActivityPub. Each server sets its own moderation policies, leading to a decentralized but fragmented experience. The servers can alternatively be called instances, relays or nodes, depending on what vocabulary a protocol has standardized on.
@username@instance.tld.
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Create",
"actor": "https://mastodon.social/users/ottok",
"object":
"type": "Note",
"content": "Hello from #Mastodon!",
"published": "2025-03-03T12:00:00Z",
"to": ["https://www.w3.org/ns/activitystreams#Public"]
Interestingly, Bluesky was conceived within Twitter in 2019 by Twitter founder Jack Dorsey. After being incubated as a Twitter-funded project, it spun off as an independent Public Benefit LLC in February 2022 and launched its public beta in February 2023.
Bluesky runs on top of the Authenticated Transfer (AT) Protocol published at https://github.com/bluesky-social/atproto. The protocol enables portable identities and data ownership, meaning users can migrate between platforms while keeping their identity and content intact. In practice, however, there is only one popular server at the moment, which is Bluesky itself.
@user.bsky.social).
"repo": "did:plc:ottoke.bsky.social",
"collection": "app.bsky.feed.post",
"record":
"$type": "app.bsky.feed.post",
"text": "Hello from Bluesky!",
"createdAt": "2025-03-03T12:00:00Z",
"langs": ["en"]
"fid": 766579,
"username": "ottok",
"custodyAddress": "0x127853e48be3870172baa4215d63b6d815d18f21",
"connectedWallet": "0x3ebe43aa3ae5b891ca1577d9c49563c0cee8da88",
"text": "Hello from Farcaster!",
"publishedAt": 1709424000,
"replyTo": null,
"embeds": []
"profileId": "@ottok",
"contentURI": "ar://QmExampleHash",
"collectModule": "0x23b9467334bEb345aAa6fd1545538F3d54436e96",
"referenceModule": "0x0000000000000000000000000000000000000000",
"timestamp": 1709558400
npub...).
"id": "note1xyz...",
"pubkey": "npub1...",
"kind": 1,
"content": "Hello from Nostr!",
"created_at": 1709558400,
"tags": [],
"sig": "sig1..."
| Platform | Total Accounts | Active Users | Growth Trend |
|---|---|---|---|
| Mastodon | ~10 million | ~1 million | Steady |
| Bluesky | ~33 million | ~1 million | Steady |
| Nostr | ~41 million | ~20 thousand | Steady |
| Farcaster | ~850 thousand | ~50 thousand | Flat |
| Lens | ~140 thousand | ~20 thousand | Flat |
Like each month, have a look at the work funded by Freexian s Debian LTS offering.
$HTTP_PROXY isn t set.
:wq for today.
I follow a few blog aggregators (or "planets") and it's always a struggle to
keep up with the amount of posts that some of these get. The best strategy I
have found so far to is to filter them so that I remove the blogs I am not
interested in, which is why I wrote
PlanetFilter.
So I started by looking for
another approach and by asking people around me how they dealt with the
firehoses that are Planet Debian and
Planet Mozilla.
It seems like a lot of people choose to "randomly sample" planet feeds and
only read a fraction of the posts that are sent through there. Personally
however, I find there are a lot of authors whose posts I never want to
miss so this option doesn't work for me.
A better option that other people have suggested is to avoid
subscribing to the planet feeds, but rather to subscribe to each of the
author feeds separately and prune them as you go. Unfortunately, this
whitelist approach is a high maintenance one since planets constantly add
and remove feeds. I decided that I wanted to follow a blacklist approach
instead.
/etc/planetfilter.d/ and
outputs filtered feeds in /var/cache/planetfilter/.
You can either:
file:///var/cache/planetfilter/planetname.xml to your local feed readerhttp://localhost/planetname.xml) using a
webserver, or[feed]
url = http://planet.debian.org/atom.xml
[blacklist]
[blacklist]
authors =
Alice Jones
John Doe
[blacklist]
titles =
This week in review
Wednesday meeting for
/etc/polipo/config:
proxyAddress = "127.0.0.1"
proxyPort = 8008
allowedClients = 127.0.0.1
allowedPorts = 1-65535
proxyName = "localhost"
cacheIsShared = false
socksParentProxy = "localhost:9050"
socksProxyType = socks5
chunkHighMark = 67108864
diskCacheRoot = ""
localDocumentRoot = ""
disableLocalInterface = true
disableConfiguration = true
dnsQueryIPv6 = no
dnsUseGethostbyname = yes
disableVia = true
censoredHeaders = from,accept-language,x-pad,link
censorReferer = maybe
/etc/default/planetfilter:
export http_proxy="localhost:8008"
export https_proxy="localhost:8008"
elektraPluginGet is the function responsible for turning information from a file into a usable KeySet. This function usually differs pretty greatly between each plug-in. This function should be of type int, it returns 0 on success or another number on an error. The function will take in a Key, usually called parentKey which contains a string containing the path to the file that is mounted. For instance, if you run the command kdb mount /etc/linetest system/linetest line then keyString(parentKey) should be equal to /etc/linetest . At this point, you generally want to open the file so you can begin saving it into keys. Here is the trickier part to explain. Basically, at this point you will want to iterate through the file and create keys and store string values inside of them according to what your plug-in is supposed to do. I will give a few examples of different plug-ins to better explain.
My line plug-in was written to read files into a KeySet line by line using the newline character as a delimiter and naming the keys by their line number such as (#1, #2, .. #_22) for a file with 22 lines. So once I open the file given by parentKey, every time a I read a line I create a new key, let s call it new_key using dupKey(parentKey). Then I set new_keys s name to lineNN (where NN is the line number) using keyAddBaseName and store the string value of the line into the key using keySetString. Once the key is initialized, I append it to the KeySet that was passed into the elektraPluginGet function, let s call it returned for now, using ksAppendKey(return, new_key). Now the KeySet will contain new_key with the name lineNN properly saved where it should be according to the kdb mount command (in this case, system/linetest/lineNN), and a string value equal to the contents of that line in the file. MY plug-in repeats these steps as long as it hasn t reached end of file, thus saving the whole file into a KeySet line by line.
The simpleini plug-in works similarly, but it parses for ini files instead of just line-by-line. At their most simple level, ini files are in the format of name=value with each pair taking one line. So for this plug-in, it makes a lot of sense to name each Key in the KeySet by the string to the left of the = sign and store the value into each key as a string. For instance, the name of the key would be name and keyGetString(name) would return value .
elektraPluginGet function is the heart of a storage plug-in, its what allows Elektra to store configurations in it s database. This function isn t just run when a file is first mounted, but whenever a file gets updated, this function is run to update the Elektra Key Database to match.
We also gave a brief overview of elektraPluginSet function. This function is basically the opposite of elektraPluginGet. Where elektraPluginGet reads information from a file into the Elektra Key Database, elektraPluginSet writes information from the database back into the mounted file.
First have a look at the signature of elektraLineSet:
elektraLineSet(Plugin *handle ELEKTRA_UNUSED, KeySet *toWrite, Key *parentKey)
Lets start with the most important parameters, the KeySet and the parentKey. The KeySet supplied is the KeySet that is going to be persisted in the file. In our case it would contain the Keys representing the lines. The parentKey is the topmost Key of the KeySet at serves several purposes. First, it contains the filename of the destination file as its value. Second, errors and warnings can be emitted via the parentKey. We will discuss error handling in more detail later. The Plugin handle can be used to persist state information in a threadsafe way with elektraPluginSetData. As our plugin is not stateful and therefore does not use the handle, it is marked as unused in order to supress compiler warnings.
Basically the implementation of elektraLineSet can be described with the following pseudocode:
open the file
if (error)
ELEKTRA_SET_ERROR(74, parentKey, keyString(parentKey));
for each key
write the key value together with a newline
close the file
The fullblown code can be found at https://github.com/ElektraInitiative/libelektra/blob/master/src/plugins/line/line.c
As you can see, all elektraLineSet does is open a file, take each Key from the KeySet (remember they are named #1, #2 #_22) in order, and write each key as it s own line in the file. Since we don t care about the name of the Key in this case (other than for order), we just write the value of keyString for each Key as a new line in the file. That s it. Now, each time the mounted KeySet is modified, elektraPluginSet will be called and the mounted file will be updated.
We haven t discussed ELEKTRA_SET_ERROR yet. Because Elektra is a library, printing errors to stderr wouldn t be a good idea. Instead, errors and warnings can be appended to a key in the form of metadata. This is what ELEKTRA_SET_ERROR does. Because the parentKey always exists even if a critical error occurres, we append the error to the parentKey. The first parameter is an id specifying the general error that occurred. A listing of existing errors together with a short description and a categorization can be found at https://github.com/ElektraInitiative/libelektra/blob/master/src/liberror/specification. The third parameter can be used to provide additional information about the error. In our case we simply supply the filename of the file that caused the error. The kdb tools will interprete this error and print it in a pretty way. Notice that this can be used in any plugin function where the parentKey is available.
The elektraPluginOpen and elektraPluginClose functions are not commonly used for storage plug-ins, but they can be useful and are worth reviewing. elektraPluginOpen function runs before elektraPluginGet and is useful to do initialization if necessary for the plug-in. On the other hand elektraPluginClose is run after other functions of the plug-in and can be useful for freeing up resources.
The last function, one that is always needed in a plug-in, is ELEKTRA_PLUGIN_EXPORT. This functions is responsible for letting Elektra know that the plug-in exists and which methods it implements. The code from my line function is a good example and pretty self-explanatory:
Plugin *ELEKTRA_PLUGIN_EXPORT(line)
return elektraPluginExport("line",
ELEKTRA_PLUGIN_GET, &elektraLineGet,
ELEKTRA_PLUGIN_SET, &elektraLineSet,
ELEKTRA_PLUGIN_END);
I ve been investigating the generation of WebID profiles for Debian project members for some time.
After earlier experiments on webid.debian.net, in a static and very hackish manner, I ve investigated the use of Django. Django is no random choice, as it is being used in several ongoing efforts to rewrite some Debian Web services.
Among these is a new LDAP UserDir, which could replace the current version which runs db.debian.org, started by Luca Filipozzi and Martin Zobel-Helas.
I ve worked on integrating some of the LDAP querying code written by Luca together with the Django WebID provider app written by Ben Nomadic (both modified by me), and the result is a bit hackish for the moment.
It s very early, but allows the generation of WebID profiles for Debian project members, using data queried in Debian s LDAP directory, and adding TLS certs to the profiles. The TLS certs could in principle be used later as a WebID + TLS authentication mechanism.
There s plenty of work ahead, and this may never be deployed, but as an example see the kind of way such WebID profile documents may look (in Turtle format) :
@prefix cert: <http://www.w3.org/ns/auth/cert#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix wot: <http://xmlns.com/wot/0.1/> . @prefix xml: <http://www.w3.org/XML/1998/namespace> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . <> a foaf:PersonalProfileDocument ; foaf:primaryTopic <http://db.debian.org/olivier#me> . <#gpgkey> a wot:Pubkey ; wot:fingerprint "ACE46EBD89F6656D6642660BE941DEDA7C5BB6A5" ; wot:pubkeyAddress <ttps://db.debian.org/fetchkey.cgi?fingerprint=ACE46EBD89F6656D6642660BE941DEDA7C5BB6A5> . <http://db.debian.org/olivier#me> a foaf:Person ; cert:key [ a cert:RSAPublicKey ; rdfs:label "key made on [...] on my laptop" ; cert:exponent 65537 ; cert:modulus "bb7d5735181c7687a09abf3c88a064513badfe351f14fc2d738978a7f573d12eb831140a7a02c579f31f4617c14145493aeff4009832ba7fd1c579d6da92f68cd4437072266b000451d6eb45c03cd00b20e1f2230d83bdc3caeebb317e6618dd38a3f53abbbb2b6495a893495d3df685a2f0f599be8a74ef88841ce283dd8f65"^^xsd:hexBinary ], [ a cert:RSAPublicKey ; rdfs:label "key made on [...] on my laptop" ; cert:exponent 65537 ; cert:modulus "b078dedb61d215348adaa3315f478eca803513a8750753255f50fd335e3b6afdafd385afb62878edc412bbbc0c125d1805abef2920cb3dccb94d818b4973435f4f312ddfad960db7b7ec4522036e5c1fb1e5d7154756a97e924075b301cdf95e97e3bb665a97cdf0187c2aa229939962b0e9975dfb97c71ea60384af465aa40726fe8a2a1dd504da6a168e7f80fc37a1363d5f583a1a8d4f8253af0e7e5c0f3d2fabb61dd9cde17aba328022fd4be4e0214f407d83a95ec06b2d70c61835bb78ba3b46e8b82be3a4d6d53d88a94123144ef9b7a7c97e9396767505f34995488c62bcd697180f92244c82147a71a5b86a25f2c8ddf0ea965fc8ced8d6b84cff97"^^xsd:hexBinary ] ; foaf:homepage <http://www.olivierberger.org/> ; foaf:mbox "mailto:obergix@debian.org" ; foaf:name "Olivier Berger" ; foaf:nick "obergix" ; wot:hasKey <#gpgkey> .If you re interested in WebID in the frame of Debian project services, see the discussion list.
:<block>!perl -MSocket -pe 's/(\d+\.\d+\.\d+\.\d+)/gethostbyaddr(inet_aton($1), AF_INET)/ge'
Account created for myaddress<at>glandium.org with hg_mozilla and mg_mozsrc bits enabled.Yes, this means I now have commit access on hg.mozilla.org. Thanks to those who vouched for me, namely Justin Wood, Christian Biesinger and Benjamin Smedberg. And thanks to the Mozilla governance for having changed the commit access requirements just in time for me to take advantage of the new ones: under the old rules, it was required that the vouching superreviewer had never reviewed a patch from the person applying for commit access. Of the 31 superreviewers, 14 (almost half of them) already had reviewed one or more patches from me (which is not really unexpected, considering the number of patches I sent in the past). One could wonder why I never applied for access earlier, though.
Water supply, in the developed world, is one of those things you just
pretty much take for granted. You turn on the tap, and clean, cool,
refreshing water comes out. Similarly, when I go to a fire in my shiny
fire truck, no matter what time of the day or night, I expect to able to
hook up to a hydrant and have a strong, steady supply of water available.
This level of reliability is something that we in the IT industry can
typically only dream of. Practically 100% reliability over a period of
decades, without constant maintenance and tweaking? Not a hope. To even
get close to that, we need clusters of fully-redundant servers, fancy
database replication techniques, and probably something totally out of
left-field like Erlang's ability to reload code on the fly.
But how do the water utilities do it? Clusters of fully-redundant
high-capacity pumps, fancy pipe re-routing techniques? Or something
totally out of left-field like a big water tank and gravity?
Where I live, we've got the latter. Thinking about how it probably
operates and is managed, I'm blown away by the sheer simplicity and
robustness of the whole design, and how it can handle all manner of
failures.
First off, consider how few components have to be working in order for
the water supply to continue for a while after some sort of catastrophic
failure. We need:
touch /tmp/keyfile chmod 600 /tmp/keyfile dd if=/dev/sda2 bs=1k count=1 of=/tmp/keyfile cryptsetup luksAddKey /dev/hda5 /tmp/keyfile wipe /tmp/keyfileNote the careful handling of the temporary key file (luksKeyAdd won't read from stdin, whereas luksOpen will), I recommend storing it on a ramdisk and you should certainly use wipe rather than rm if you don't. Once you have added your USB key you could remove the passphrase from the key list with luksDelKey, but if for any reason you lose the USB hdd you will be unable to decrypt the partition; I recommend leaving both keys available. Booting automatically In order to boot using the USB key we need to provide a couple of helper scripts in order for the initramfs to work. We also need to set some parameters on the kernel command line. In Debian these scripts can be added to the initramfs by putting them in /etc/initramfs-tools/. The first script is a helper script used when building the initramfs. This writes a second script into the initramfs itself which takes the partition as a parameter and prints the key on stdout. This should be written to /etc/initramfs-tools/hooks/cryptkey (executable) and contain:
#!/bin/sh -- PREREQ="" prereqs() echo "$PREREQ" case $1 in prereqs) prereqs exit 0 ;; esac . /usr/share/initramfs-tools/hook-functions cat > $ DESTDIR /bin/loadkeyThe second script runs immediately before the cryptsetup script in the initramfs and ensures that the USB disk is available. This will cause the boot sequence to block until the USB disk is inserted and the device nodes created by udev. It can be provided directly in /etc/initramfs-tools/scripts/local-top/00ensureusb (executable) and should contain:
#!/bin/sh --
PREREQ=""
prereqs()
echo "$PREREQ"
case $1 in
prereqs)
prereqs
exit 0
;;
esac
if ! grep cryptopts /proc/cmdline >/dev/null; then return; fi
. /scripts/functions
log_begin_msg "Waiting for USB to become available..."
modprobe usbcore
modprobe uhci_hcd
modprobe ehci_hcd
modprobe usb_storage
while [ ! -b /dev/sda2 ]; do
sleep 1
done
log_end_msg
exit 0
The cryptsetup script itself reads configuration from the kernel command
line. Here you can give it a script which will read the key and the
source for the key to read. Edit your grub or lilo config and append
the following to the kernel command line:
cryptopts=keyscript=/bin/loadkey,key=/dev/sda2,source=/dev/hda5,target=hda5_crypt,lvm=hecate-root
You will obviously have to change the name of your lvm root partition
(volumegroup-logicalvolume). I recommend having two entries in the
boot menu, one with the cryptopts and one without to allow easy
decryption using the passphrase instead.
Conclusion
That should be everything. Boot your computer and inset the usb hdd.
When the boot process passes decryption you can remove it again. You
may have to replug it if you boot with it inserted to start with.
I don’t know the English idiom for “tocar las narices”, but if they do it to me, I’ll adopt this name and logo for my translation. And then, if I translate Thunderbird, I’ll call this one “Thunderchicken” :-)