jrollans.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
HIS FATHER’s SON; SAMWISE! #mastodon #fediverse #photography #photo #dogsofmastodon #dogs #pets #Monday
🛡️ #Cybersecurity news & tips across the #fediverse
“ICYMI⚡"The Steady State, an organization of more than 415 former national security, intelligence, diplomatic, military, law enforcement, & homeland security officials, on Thursday filed a federal lawsuit against the # D...”
https://toad.social/@KimPerales/116833489113713461
🤖 via RSS feed. Not an endorsement.
Diese Veranstaltung ist im Januar. Ja, das ist lange hin, aber ich werde euch von jetzt an regelmäßig damit pesten. Denn wenn 2 Wochen vorher nicht über 30 Tickets verkauft sind, fällt die Chose aus. Also, #fediverse ich suche eure Macht! Gibt es hier Menschen, die intelligente Kunst am Leben halten möchten? Weihnachten kommt früher als ihr denkt: kauft ein Ticket! 😜
https://www.vorderhaus.de/programm/martina-brandl-prima-fein-gemacht
#kleinkunst #kabarett #live #livemusic #livekultur #kultur #show #primafeingemacht #martinabrandl
🛡️ #Cybersecurity news & tips across the #fediverse
“What is a blockchain messenger, really? Most apps hide what you say. They still see who you talk to, and when. That metadata is the part surveillance wants. Z-TEXT stores messages on-chain instead of a company server. ...”
https://mastodon.social/@Z_text_blockchain_messenger/116832733966188520
🤖 via RSS feed. Not an endorsement.
"What do you want to do?"
The new https://fediverse.info will be a powerful onboarding resource, and is shipping later this week!
Take a good look at https://fediverse.info
A new and much improved version is shipping later this week ✨
🛡️ #Cybersecurity news & tips across the #fediverse
“‘It’s dangerous and it’s going to erode # trust ’: redesign of US government websites stokes # surveillance fears | # Trump administration | The Guardian
The National Design Studio, staffed by # DOGE vete...”
https://mas.to/@PrivacyDigest/116831519876633027
🤖 via RSS feed. Not an endorsement.
Kognitive Dissonanz & Reaktanz betreffen am Heftigsten - aber eben nicht ausschließlich - Rechte.
So weiß ich jetzt schon, dass auch viele hier auf Mastodon die Nachrichtenlage zur via Iran fossil finanzierten Hisbollah abwehren werden:
Die Regierungen von Israel 🇮🇱 und des Libanon 🇱🇧 haben sich auf einen Frieden & Rückzug der IDF geeinigt - wenn die Terrorgruppe entwaffnet ist. Doch diese weigert sich, lehnt den Frieden ab.
Da viele Progressive sich auf eine Lesart festgelegt haben, wonach die israelische Armee IDF der Aggressor sei, werden auch sie diese kognitive Dissonanz als schmerzhaft empfinden und (am Besten durch mimetische Schein-Bestätigung in der eigenen Medienblase) abzuwehren versuchen. Leider. (2/2)
#Psychologie #kognitiveDissonanz #Reaktanz #Rechte #Linke #Fossilismus #Antisemitismus #Iran #Hisbollah #Israel #Libanon #Medien #Blase #Mastodon #Fediverse #Dialog #Dualismus #Krieg #Frieden
FediCon: The Canadian Fediverse Conference in Vancouver later this summer is happening!
It's not too late to propose a talk or buy tickets.
Spread the word ✨
🛡️ #Cybersecurity news & tips across the #fediverse
“Holy crap, this is a privacy and surveillance disaster. https:// bsky.app/profile/chrisnelder.b sky.social/post/3mpeuc3dloc2h “The National Design Studio, staffed by Doge veterans, installed visitor-tracking sof...”
https://mstdn.social/@990000/116829911961008229
🤖 via RSS feed. Not an endorsement.
A couple of thoughts.
1) If spam bot is a business, do they really find an economic incentive in the #fediverse ?
Isn't significally lower, like programming viruses for windows is more convenient than for linux or osx
(well, i guess this will change also)
2) why don't the AI bots simply fire up their own instance and start following people, instead of counting on accounts being approved
Tomato and Basil III - Available Here: https://1-lisas-baker.pixels.com/featured/tomato-and-basil-iii-lisa-s-baker.html
#tomato #tomatoes #food #foodart #basil #herbs #vegetables #kitchenart #kitchendecor #artforhome #artforsale #buyintoart #artprints #canvasprints #mastoart #fediart #fediverse #creativeToots
🛡️ #Cybersecurity news & tips across the #fediverse
“RE: https:// mastodon.social/@chatcontrol/1 16812506724557428 I just sent the emails as suggested by @ chatcontrol because # surveillance is just one of the first steps toward # oppression . Thank you f...”
https://mastodon.social/@marcow/116829623426908009
🤖 via RSS feed. Not an endorsement.
I miss the old small internet: Carracho, BBSs, IRC, AIM/MSN, radio, forums, little communities where you knew who was online. Looking for kindred spirits — old web, radio, photography, cycling, analogue tech, slow internet, proper conversations..
#OldInternet
#BBS
#Hotline
#Carracho
#IndieWeb
#Fediverse
#AmateurRadio
#Shortwave
#RetroComputing
@stadtulm Im Prinzip eine nette Idee, aber dann lese ich das hier:
"Das Gewinnspiel wird auf den Social-Media-Plattformen Instagram und Facebook veröffentlicht."
Fühlt sich ein wenig deplatziert an, hier im #fediverse, oder?
Thank you for this article, Elena.
To sum up: People on the #fediverse, the network that European career politicians decided was beneath them, help VC-backed #wsocial get their act together.
Fedi, you are too good for this world.
🛡️ #Cybersecurity news & tips across the #fediverse
“Set a reminder for yourself to call your congressional representatives tomorrow! We can't let the government dismantle more of our digital freedom on Big Tech's behalf. From @ fight :
‼️ Bad Internet Bills, disgui...”
https://defcon.social/@fldigitalrights/116829121183831455
🤖 via RSS feed. Not an endorsement.
Monday Monday...
Last night there was a blackout for over an hour. The local substation overloaded because everyone in the area had their AC running on full blast. And this week they say they're coming to finish the FTTH installation.
My wife bets that the appointment will fall through this time too.
We'll see!
Have a great week, #BSDCafe
Have a great week, #illumosCafe
Have a great week, #Fediverse
@_elena it angers me that VDL and Lagarde jumped on this bandwagon apparently without any vetting – just based on some weird backroom Davos connections and apparently hold themselves too good for and too high and mighty for a presence on the open democratic #fediverse. 😠
They should plusOne the Fediverse.
#plusOne
🛡️ #Cybersecurity news & tips across the #fediverse
“Sick of fighting them resurrecting Chat Control again and again and again ? Stop asking nicely. Hit them where it hurts - organise to leave the EU. # eu # eupol # chatcontrol # surveillance # security ...”
https://mastodon.ie/@rzeta0/116828667962105086
🤖 via RSS feed. Not an endorsement.
🛡️ #Cybersecurity news & tips across the #fediverse
“RE: https:// social.lansky.name/@hn100/1168 28485146491866 Anyone know whether these are in Washington state? I haven’t seen them, but…perhaps we should drag Aurora Ave above 90th in Seattle?
# FlockCameras #...”
https://mastodon.green/@odaraia/116828560299528894
🤖 via RSS feed. Not an endorsement.
🛡️ #Cybersecurity news & tips across the #fediverse
“In clear violation of the # PrivacyAct of 1974 & the E-Government Act of 2002: # WhiteHouse "now operates four public # federal # websites : ndstudio.gov, trumprx.gov, realfood.gov & trumpaccounts.gov."
All a...”
https://masto.nyc/@GetMisch/116828335053355374
🤖 via RSS feed. Not an endorsement.
Want to watch Zarkorr! The Invader (1996) in tonight's #Monsterdon #WatchParty ?
The collection on #NeoDB ( #Fediverse alternative to Letterboxd etc) now has links for:
- streaming video on demand
- download on demand
- scheduled stream
- search for more streams & downloads
https://eggplant.place/collection/6ICD4rDFsYEIcTpY8UTpdk
Ad-free options are Miru, downloads & Internet Archive, or use one of the options here:
https://ohai.social/@klu9/115245207831850566
🛡️ #Cybersecurity news & tips across the #fediverse
“Analysis of the underlying source code for four of the websites written by the secretive National Design Studio (NDS)
found that on at least two of them,
the studio installed a commercial tool called PostHog
that cl...”
https://c.im/@cdarwin/116828322225558491
🤖 via RSS feed. Not an endorsement.
Since @evan@cosocial.ca seems unable (or unwilling) to understand that many users desire the #FediVerse to be a place where opt-in is the normal and expected implementation for features such as #relays I propose that #fedidevelopers take up this call.
The problem: the implementation of relays lacks sufficient user-based controls. While users may (at least on platforms such as GotoSocial) add relays they desire to have their content sent to, there are no user based controls over relays configured at the instance level.
The current implementation appears to have unintended, and unconsidered consequences associated with it.
Ban evasion can likely be achieved through chaining relays together. We have already seen the unintended consequence of a relay following tags.pub leading to content being relayed non-consensually.
Something that has not been considered is potential damages to users in regions where political, social, or religious beliefs are sensitive topics need to maintain tight controls over where their content is sent. This is a case where the handling and relaying of posts needs to be 100 percent bulletproof.
The Solution: all platforms in the Fediverse should implement instance level relays in the following manner:
Through this implementation we avoid clunky workarounds like adding hashtags to profiles. Also, we make this feature more discoverable for new users who are unfamiliar with the conventions of the FediVerse.
I am unfamiliar with the #FEP submission process and requirements. Anyone willing to work with me on this, I would like to see this brought forth as a FEP.
#fedideveloperverse #fedideveloper #mastodon #gotosocial #misskeyworld #misskey #pixelfed #microdotblog #pleroma #sharkeydev
@alice @admin @gotosocial @Gargron
When you're a Very Important user on the #Fediverse, and you spend 3+ hours writing dozens of responses about how something is opt-in actually (it isn't), and that you understand consent (after-the-fact), maybe you should take the next 3 hours to reflect on how wrong you are.
Hello everyone on #mastodon ,if you want to earn money easier grow cabbage because they take less time to get harvest.
And fighting hidden hungers in schools and communities they have helped us much more, so if you would like joining us. Welcome together we can grow.
#Today or #tomorrow
#gardening #2024Election #nature #c108webcatalog #free #love #local #farmers #environment #agroecology #climatechange #fediverse #solarpunksunday #performance
🛡️ #Cybersecurity news & tips across the #fediverse
“Fascism is alive & kicking all opposition very hard under Trump’s NSPM7-driven, 100-year-long jail term, Palantir-enabled Hitlerite ‘Gleichschaltung’ regime! “Hot Type: The Machinery of the Fascist State” by Heidi Cud...”
https://expressional.social/@GrumpyOldFart/116827873288651569
🤖 via RSS feed. Not an endorsement.
When's the last time you went to Preferences > Accounts and checked how many sessions you've got open?
Assumes standard Mastodon 4.x. Not Misskey, its variants, or other frontends.
@alice @frog_reborn Also it's good to remind everyone the #Fediverse isn't the "Move Fast And Break Things!" corner of the internet but the "Move Slow And Build Things!" corner!
https://mastodon.social/@kkarhan/116828967395800309
#MoveSlowAndBuildThings #MoveFastAndBreakThings #Fediverse #CommunityCare
Welcome to an interactive map of electronic sound evolution. From the first experiments with electricity to neural audio. Navigate the timeline, explore events, listen to music.
#music #fedimusic #fediverse #history #interactive #map #electronicmusic #experimentalmusic #sound #evolution #electricity #neural #radio #synth #synthetizer #study #nodemusic
tags.pub has unsubscribed from all open relays. Evan recognises there's a mismatch of expectations on what Relay 2 relay, R2R connections should be like.
It should not have taken as long as it did but it's done. However this is ultimately a stop gap and not a full solution. What was asked for was an opt-in solution because there is value in having relays of relays.
So on the tags.pub issue, how should R2R relays gain consent?🧵
🛡️ #Cybersecurity news & tips across the #fediverse
“The Supreme Court is building its own massive police force https://www.politico.com/news/magazine/2026/06/28/supreme-court-justices-security-police-00969784?utm_source=RSS_Feed&utm_medium=RSS&utm_campaign=RSS_Syndicatio...”
https://social.espeweb.net/objects/2001838a-9aa5-4d4d-8042-5ed1be095e71
🤖 via RSS feed. Not an endorsement.
@maxleibman I think that for most hashtags, there are multiple authors that use the tag. I don't think anyone owns the #fediverse hashtag.
I added a ticket to track this issue. It makes me uncomfortable to think that anyone "owns" a hashtag. But others don't agree, so I'd like to find an accommodation.
🛡️ #Cybersecurity news & tips across the #fediverse
“Content warning: EU chat control 1.0, and 2.0, eupol, its back EU chat control 1.0 and 2.0 are back on the menu and this time they are passing them behind closed doors in the next few days.
We need to email our rep...”
https://woem.men/notes/ao140np5x9wx064x
🤖 via RSS feed. Not an endorsement.
I have written before about putting a cache in front of snac (https://it-notes.dragas.net/2025/01/29/improving-snac-performance-with-nginx-proxy-cache/), and more recently about the HAProxy layer in front of FediMeteo (https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/). The general idea is always the same: the reverse proxy should absorb the repetitive, public work that has no business reaching the application server.
This post is the same idea applied to a much louder neighbour: a Mastodon instance. The instance is mastodon.bsd.cafe (https://mastodon.bsd.cafe/), the proxy is nginx on FreeBSD, and the configuration below is what I am currently running in production.
Mastodon is heavier than snac in every direction. It has Puma and Sidekiq behind it, more endpoints, more streaming, more federation patterns, and one specific characteristic that complicates everything: it serves multiple representations on the same URLs. The same path returns HTML to a browser, ActivityPub JSON to a remote instance, and sometimes plain JSON to an API client. If the proxy treats the URL as one thing, sooner or later it will return the wrong thing to the wrong client.
Most of the work below comes from that single observation.
If I had to summarize this whole post in a single sentence, it would be this:
Mastodon is not a website. It is a website, an API, and an ActivityPub server, all sharing the same URLs.
Everything else in this configuration - cache keys, variants, bypass rules, the diagnostic headers - is decoration around that one fact.
A popular toot from a friend gets boosted. Twenty federated instances ask for the same ActivityPub object within the same second. Browsers fetch the HTML version of the same URL. If the proxy sees only "a URL", it will eventually betray you: a remote instance will receive HTML, a browser will receive ActivityPub JSON, and you will spend an afternoon wondering why your timeline looks broken on three different servers. I have spent that afternoon. I do not recommend it.
The first assumption is that AUTHORIZED_FETCH (secure mode) is disabled. With secure mode off, all ActivityPub GET responses cached at the proxy layer are public and identical regardless of the requesting actor. With secure mode on, Mastodon can legitimately return different bodies depending on which remote actor is asking, and caching them blindly at the proxy becomes at best wasteful, at worst a cache-poisoning surface.
This is not a hypothetical. CVE-2026-25540 (https://nvd.nist.gov/vuln/detail/CVE-2026-25540), fixed in Mastodon 4.3.19, 4.4.13, and 4.5.6, is exactly this kind of mistake, but inside Mastodon's own Rails.cache: the pinned posts and featured hashtags endpoints had actor-dependent ActivityPub responses but were keyed without the actor. The CVE does not directly apply to nginx caches, but the underlying lesson does. Do not cache what depends on the caller unless the caller is part of the cache key. Keep this rule in mind every time you are tempted to cache a federation endpoint "just in case".
The second assumption is that no signed-URL storage backend sits behind /system/ or /media_proxy/. If those paths ever redirect to short-lived presigned S3 or SeaweedFS URLs, my TTLs below are too long: nginx will happily cache a redirect to a URL that has already expired.
The third assumption is that federation traffic uses HTTP Signatures, not the HTTP Authorization header. Mastodon signs federated GETs with the Signature header. The Authorization-based skip-cache rule further down catches API tokens, not signed federation traffic. If you enable AUTHORIZED_FETCH, you must add an explicit skip rule for $http_signature.
I am being deliberate about these assumptions because the configuration that follows is internally consistent only as long as they hold.
The proxy in front of mastodon.bsd.cafe has three jobs:
TLS termination, microcaching of expensive endpoints (especially federation-heavy collections and default public routes), and long-lived caching of immutable assets and user media.
The point is not to replace Mastodon's internal Rails cache. The point is to absorb spiky federation traffic and repetitive asset fetches that would otherwise hit Puma and Rails for every single request.
The strategy is deliberately layered: very long TTL on fingerprinted assets, medium TTL on user-uploaded media, very short microcache on dynamic pages and federation endpoints that get hammered, and explicit bypass rules for anything private, authenticated, actor-dependent, or otherwise unsafe.
Every cacheable layer is keyed correctly for content negotiation. That is the part that matters most.
proxy_cache_path /var/cache/nginx/mastodon
levels=1:2
keys_zone=mastodon_cache:200m
max_size=20g
inactive=24h
use_temp_path=off;
200m of keys zone holds metadata for roughly 1.6 million entries in RAM. The body can grow up to 20g on disk. The two numbers are independent: keys live in shared memory, bodies live on the filesystem, and the cache key is what links them.inactive=24h evicts anything not requested for a day, even if there is free space. This is intentional. I do not want a long, cold tail of stale entries to squat in the cache forever. I want the working set to remain hot, and I want the rest to fade.
use_temp_path=off is small but important. By default nginx writes a cached response to a temporary file and then renames it into place. If the temp path and cache path are on different filesystems, that cheap rename becomes a real copy. Setting use_temp_path=off puts temporary files directly under the cache directory and avoids that trap. It is the kind of detail nobody mentions until something is suspiciously slow.
Of all the maps in this configuration, only one really earns its place. This one:
map $http_accept $mastodon_cache_variant {
default "default";
"~*application/activity\+json" "activitypub";
"~*application/ld\+json" "activitypub";
"~*application/json" "json";
"~*text/html" "html";
}
Mastodon serves the same URL with different bodies depending on the Accept header. A status URL like /@user/123456789 returns rendered HTML to a browser and an ActivityPub object to another federated instance. If you cache by URL alone, the first request that comes in wins and the next request receives the wrong content type. Instances start federating HTML, browsers start downloading JSON, and the failure is subtle enough to waste hours.The map normalizes Accept into four buckets - activitypub, json, html, and default - and the result is folded into the cache key in every location that does content negotiation:
proxy_cache_key "$scheme$host$request_uri|accept=$mastodon_cache_variant";Coalescing equivalent MIME types is intentional.
application/activity+json and application/ld+json both map to activitypub, because splitting them across two cache buckets would fragment the cache for no useful operational gain.A subtle point I want to be explicit about: I do not include $request_method in the cache key. nginx already converts HEADinto GET for caching purposes by default, which is what I want here. A HEAD request on /@user/123 should hit the same cache entry as a GET request on the same URL. Adding the method would only separate them for no benefit.
During rollout I also expose the selected variant as a response header:
add_header X-Cache-Variant $mastodon_cache_variant always;The header is there to verify the behaviour in production. It can come off once the configuration has proved itself, but I tend to leave it on. A cache that works should be visible. A cache that is invisible can be correct, but it can also be silently wrong, and I would rather know.
This is the first real gotcha, and I want to spend a moment on it because it caught me out the first time I configured a similar setup.
nginx honors the upstream Vary response header in addition to proxy_cache_key. If Mastodon emits Vary: Accept, or worse, Vary: Accept, Cookie, ..., my carefully normalized variant key gets paired with nginx's native Vary handling. The result is that the cache may still fragment on the full, un-normalized Accept header - which defeats the entire point of the variant map.
There is another, very specific failure mode on older or unpatched nginx builds. nginx stores the Vary value in a fixed-size cache metadata field. Historically that field was 42 bytes, which is famously short and almost charmingly suspicious of being a Douglas Adams reference. Modern nginx raised the limit to 128 bytes, which is enough for the common cases but still surprisingly small. If your upstream emits a long Vary header, anything beyond the limit is treated as Vary: *, which means the response is not cached at all. The only signal you get is a critical line in the error log, and unless you are looking for it, you will not see it.
The operational lesson is the same in both cases: if you rely on your own normalized variant key, do not assume upstream Vary is harmless. Check your nginx version, check your error log, and verify cache behaviour via X-Cache-Statusand X-Cache-Variant.
On the locations where the variant map is the cache dimension I care about, I take responsibility explicitly:
proxy_ignore_headers Vary;This tells nginx to stop using upstream
Vary to protect me. That is fine only if my own cache key and request normalization cover every response dimension that matters. In particular, I make sure the backend is not also varying on Accept-Encoding in a way that would create compressed and uncompressed variants behind my back. The cleanest way to avoid that is not to forward Accept-Encoding to the backend at all, and let frontend nginx handle compression itself:proxy_set_header Accept-Encoding "";This is the kind of decision I prefer to be explicit about. Ignoring
Vary is not magic. It is a responsibility, and it should be paired with the rules that take its place.Rather than build one giant boolean to decide what bypasses cache, I prefer to decompose the logic into small orthogonal maps. Each map is 1 when caching must be skipped, and the final decision is an OR of all of them.
map $request_method $skip_cache_method {
default 1;
GET 0;
HEAD 0;
}map $http_authorization $skip_cache_auth {
default 1;
"" 0;
}
map $http_cookie $skip_cache_cookie {
default 1;
"" 0;
}
map $uri $skip_cache_uri {
default 0;
~^/auth 1;
~^/oauth 1;
~^/settings 1;
~^/admin 1;
~^/api/v1/custom_emojis$ 0;
~^/api/v1/instance$ 0;
~^/api/v2/instance$ 0;
~^/api/v1/trends/tags$ 0;
~^/api/oembed$ 0;
~^/api/ 1;
}
The reasoning is straightforward. Only GET and HEAD are cacheable; everything else, including POST, DELETE, PUT, and ActivityPub deliveries, must pass through. Any request carrying an Authorization header is an API call with a token, and those are never public. Any request with a cookie is potentially logged-in traffic, and caching logged-in pages would leak personal timelines across users. Auth flows, settings, admin, and most of the API bypass the cache by URI, while a small, carefully chosen set of slow-changing public API endpoints is allowed through.The important caveat I want to underline: the Authorization map does not catch signed federated GETs. Mastodon federation uses HTTP Signatures, which means the relevant request header is Signature. If AUTHORIZED_FETCH is enabled, you must add a parallel map:
map $http_signature $skip_cache_signature {
default 1;
"" 0;
}
and then include it in both proxy_cache_bypass and proxy_no_cache. Do this before enabling secure mode, not after.The maps are used together in each cacheable location:
proxy_cache_bypass $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;Both directives are necessary.
proxy_no_cache $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_cache_bypass means "do not read from cache for this request". proxy_no_cache means "do not write this response to cache". Without proxy_no_cache, a logged-in user's response could still poison the anonymous cache. Without proxy_cache_bypass, a request that should have gone straight to the backend might still receive a cached anonymous response. I keep both, every time.Most locations share a common proxy baseline. There is nothing clever here, but if any of these lines is missing the rest of the configuration quietly does less than expected.
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection "";
proxy_set_header Accept-Encoding "";
proxy_http_version 1.1 and proxy_set_header Connection "" matter for upstream keepalive. Without them, nginx may use HTTP/1.0 semantics upstream and send Connection: close on every request, which makes the keepalive directive on the upstream block far less useful than it looks.proxy_set_header Accept-Encoding "" keeps backend responses uncompressed so nginx can cache a single representation and handle client-facing compression itself. It also prevents accidental cache fragmentation through Vary: Accept-Encoding, which would otherwise creep in despite the variant map.
These settings are not exciting, and they should not be. The interesting parts of an infrastructure are not always the parts that should be unusual.
The Mastodon server block in my configuration ends up with seven distinct request profiles. Six of them cache; one explicitly does not, because streaming is not a cacheable workload.
I do not group them under one location / with a giant if block. I prefer to keep each profile in its own location, even if some of them look similar. When something goes wrong in production, I want to be able to point at one location and reason about it without holding the rest of the configuration in my head.
location ~ ^/(assets|packs|emoji)/ {
proxy_cache mastodon_cache;
proxy_cache_key "$scheme$host$request_uri";
proxy_ignore_headers Vary; proxy_cache_valid 200 301 302 7d;
proxy_cache_valid 404 10m;
proxy_cache_lock on;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_bypass $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_no_cache $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_pass http://$custom_upstream;
}
These paths are content-addressed. Webpack fingerprints filenames with hashes, so a new deploy publishes new URLs while the old URLs remain valid. A 7-day TTL is safe because /packs/js/common-abc123.js will never become different content under the same URL. If it does, it has a new URL.404s get a short 10-minute TTL so a temporarily missing asset can recover quickly.
proxy_cache_lock on is the thundering-herd guard. When a popular asset is not cached and ten clients ask for it at once, nine wait for the first request to populate the cache instead of all ten hammering the backend. I like this directive a lot. It is the kind of small switch that quietly removes a class of problems.
proxy_cache_use_stale together with proxy_cache_background_update is the stale-while-revalidate pattern. If an entry has expired but Mastodon is slow or briefly down, nginx can serve the stale copy and refresh it asynchronously. For static assets this is almost always the right trade-off. The asset has not actually changed under the same URL, and a few extra hours of stale data hurt nobody.
location ~ ^/system/(accounts/avatars|media_attachments/files|custom_emojis/images)/ {
proxy_cache mastodon_cache;
proxy_cache_key "$scheme$host$request_uri";
proxy_ignore_headers Vary; proxy_cache_valid 200 302 6h;
proxy_cache_valid 404 5m;
proxy_cache_lock on;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_bypass $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_no_cache $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_pass http://$custom_upstream;
}
Avatars, attachment thumbnails, and custom emoji are also effectively content-addressed, because the file path contains an ID. They can still be replaced or deleted, so the TTL is more conservative than for assets: six hours instead of seven days.The 302 status is also cached, because Mastodon may redirect to another storage location, and the redirect is usually stable enough to cache for hours.
This is also where the caveat about signed URLs really matters. If you ever put a signed-URL backend behind /system/, this TTL must be shorter than the signed URL lifetime, or nginx will eventually serve a redirect to a URL that no longer works. On mastodon.bsd.cafe I do not use signed URLs, so six hours is fine.
location ~ ^/(users|ap/users)/[^/]+/statuses/[0-9]+/replies {
proxy_cache mastodon_cache;
proxy_cache_key "$scheme$host$request_uri|accept=$mastodon_cache_variant";
proxy_ignore_headers Vary; proxy_cache_valid 200 30s;
proxy_cache_valid 404 10s;
proxy_cache_lock on;
proxy_cache_lock_timeout 1s;
proxy_cache_lock_age 5s;
proxy_cache_bypass $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_no_cache $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_pass http://$custom_upstream;
}
This is the location I tuned most carefully. When a status starts going viral, dozens of federated instances poll /replies to build their thread view, often within the same second. The same URL must serve an HTML thread view to browsers and an ActivityPub OrderedCollection to remote instances, so the variant key is essential here.A 30-second microcache absorbs the spike without serving meaningfully stale data. A reply that appears 30 seconds late in a federated thread is usually invisible to humans, while the backend relief is very visible.
The lock settings keep backend load and latency bounded. proxy_cache_lock_timeout 1s bounds how long queued requests wait behind the lock. If the timeout expires, they go to the upstream directly, but their responses are not stored in the cache, which prevents a runaway thundering herd from clogging the cache fill path. proxy_cache_lock_age 5s prevents one slow cache-populating request from monopolizing the fill path forever; if the request holding the lock has not completed after 5 seconds, nginx may let another request reach the upstream to retry.
I have currently left proxy_cache_use_stale off on this location while I am still validating the deployment. This is a deliberate debugging stance, not a permanent choice. Stale-while-revalidate is useful in production, but during rollout it can hide upstream issues while I am trying to understand the system. Once the behaviour is stable, the production version will be:
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
location ^~ /media_proxy/ {
proxy_cache mastodon_cache;
proxy_cache_key "$scheme$host$request_uri"; proxy_cache_valid 200 10m;
proxy_cache_valid 301 302 10m;
proxy_cache_valid 404 1m;
proxy_ignore_headers Cache-Control Expires Vary;
proxy_cache_lock on;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_background_update on;
proxy_cache_bypass $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_no_cache $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_pass http://$custom_upstream;
}
Mastodon's /media_proxy/ fetches remote media so clients do not leak their IP address to remote servers. The response is the same regardless of Accept, so the cache key intentionally omits the variant. Splitting media proxy responses across html, json, activitypub, and default buckets would only waste storage.proxy_ignore_headers Cache-Control Expires Vary is deliberate here. Mastodon may emit conservative cache headers, or none at all, and I want the proxy to enforce a short local 10-minute policy regardless of what the backend says.
Set-Cookie is not in the ignore list. nginx's default refusal to cache responses carrying Set-Cookie still applies, and I want it to. It is a safety net I do not want to disable just to win a few cache hits.
The ^~ prefix is a small useful detail. Once this location matches, nginx stops evaluating regex locations. Media proxy traffic can be heavy, and skipping further regex matching is a tiny but free win.
location ~ ^/(users|ap/users)/[^/]+/(followers|following) {
proxy_pass http://$custom_upstream;
}
This one is a pure proxy, no cache. I want to be explicit that this is a decision, not an omission./users//followers and /users//following are pagination-heavy, change frequently as people follow and unfollow, and are queried by federation crawlers in ways that would make the cache key proliferate through pages and cursors. The likely hit ratio is poor, the risk of serving stale social graph data is non-trivial, and the cost of caching them - in storage and in mental overhead - is not worth it.
If a remote instance starts hammering these endpoints, the right answer is rate limiting with limit_req_zone, not retrofitting cache as a rate limiter.
location / {
proxy_cache mastodon_cache;
proxy_cache_key "$scheme$host$request_uri|accept=$mastodon_cache_variant";
proxy_ignore_headers Vary; proxy_cache_valid 200 10s;
proxy_cache_valid 301 302 1m;
proxy_cache_valid 404 10s;
proxy_cache_lock on;
proxy_cache_lock_timeout 5s;
proxy_cache_bypass $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_no_cache $skip_cache_method $skip_cache_auth $skip_cache_cookie $skip_cache_uri;
proxy_next_upstream error timeout http_502 http_503 http_504;
proxy_next_upstream_tries 2;
proxy_pass http://$custom_upstream;
}
Everything not matched by a more specific location falls here: profiles, individual statuses, the about page, the public timeline, and many ActivityPub object fetches.The TTL is only 10 seconds for 200 responses. That is enough to deduplicate the wave of requests when a popular toot gets boosted or linked from elsewhere, without making the page feel stale to a human visitor.
It is worth being honest that short TTLs still cost CPU. A 10-second microcache on a sustained-traffic URL means the backend regenerates the entry six times per minute. That is vastly better than serving every request from Rails, but it is not free. If your backend cannot comfortably handle that, raise the TTL, or enable stale-while-revalidate on these dynamic paths.
proxy_next_upstream with proxy_next_upstream_tries 2 is the failover trigger. If the primary returns 502, 503, 504, or times out, nginx retries on the backup. The chain is capped at two attempts so a sick upstream cannot hold the request indefinitely.
At the http level:
map $http_upgrade $connection_upgrade {
default upgrade;
"" close;
}
In the server block:location /api/v1/streaming {
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
proxy_pass http://$custom_upstream;
}
Streaming is a WebSocket and SSE-style endpoint. Buffering must be off, otherwise the proxy may hold messages while waiting for buffers to fill. The Upgrade and Connection headers are driven by $connection_upgrade, which is upgradeonly when the client actually sent an Upgrade header. That way a non-WebSocket request to the same path does not get its Connection header mangled.The hour-long read and send timeouts allow long-lived streams to stay open through quiet periods.
There is no cache here. Streaming is not a cacheable workload, and trying to make it one is one of those ideas that sounds clever for about thirty seconds.
upstream mastodonbsdcafe {
server 192.168.123.33 max_fails=3 fail_timeout=30s;
server 192.168.122.133 backup;
keepalive 64;
}
The primary backend is on another VPS; the backup is in a jail next to the reverse proxy. After three consecutive failures, the primary is marked down for 30 seconds. Traffic flips to the backup, then nginx retries the primary after the window.keepalive 64 holds up to 64 idle TCP connections to the upstream per worker. On a busy instance, this saves real handshake overhead, but only if the proxied connection can actually stay open. That is why the shared proxy settings include proxy_http_version 1.1 and proxy_set_header Connection "". Without those, upstream keepalive does much less than it looks like it should.
I also use an indirection layer:
map $remote_addr $custom_upstream {
default mastodonbsdcafe;
}
Today everything defaults to the main upstream group. The map exists so that specific client IPs can be pinned to a specific upstream when I am debugging, or so an admin connection can be routed to the backup while the primary is being tested. It costs nothing to have it sitting there, and it has saved me time more than once.log_format detailed '$remote_addr - $remote_user [$time_local] 'This log format is purpose-built for the cache layer. For each request it records total request time, upstream connect time, upstream header time, upstream response time, upstream status, which backend served the request, cache status, and which content-negotiation variant was selected.
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time '
'uct=$upstream_connect_time '
'uht=$upstream_header_time '
'urt=$upstream_response_time '
'us=$upstream_status '
'ua=$upstream_addr '
'cache=$upstream_cache_status '
'variant=$mastodon_cache_variant';access_log /var/log/nginx/access.mastodon.bsd.cafe.log detailed;
add_header X-Cache-Status $upstream_cache_status always;
add_header X-Cache-Variant $mastodon_cache_variant always;
The cache status is one of the values nginx exposes through $upstream_cache_status: HIT, MISS, BYPASS, EXPIRED, STALE, UPDATING, or REVALIDATED. The response headers expose the same information to the client, which makes it trivial to verify behaviour with curl -I or browser dev tools.
The always qualifier matters. Without it, nginx only adds these headers to a subset of responses, so a 502 from the backend might arrive without the diagnostic headers you need most. I want them on every response, no exceptions.
There is also a small operational detail I find pleasant: a custom 502 page.
error_page 502 /502.html;It is not part of the cache strategy, but it makes backend hiccups less ugly. And I block some abusive user agents with
location = /502.html {
root /usr/local/www/mastodon_errors;
internal;
}
444, which closes the connection without sending any response at all:if ($http_user_agent ~* "bytespider") {
return 444;
}
This is not a general bot strategy. It is just a cheap refusal path for traffic I know I do not want.The first verification is variant separation. Three requests to the same URL with different Accept headers should produce three independent cache entries:
for v in 'text/html' \On the first pass, every variant should be a
'application/activity+json' \
'application/ld+json; profile="https://www.w3.org/ns/activitystreams"'; do
printf '%-75s -> ' "$v"
curl -s -o /dev/null -D - -H "Accept: $v" \
https://mastodon.bsd.cafe/@someuser/123456789 \
| awk '/^[Xx]-[Cc]ache/ { printf "%s ", $0 } END { print "" }'
done
MISS. On the second pass, every variant should be a HIT, with X-Cache-Variantshowing the expected bucket.The second verification is that cookies and Authorization always trigger BYPASS:
curl -I -H 'Cookie: _mastodon_session=test' \Both should return
https://mastodon.bsd.cafe/@someusercurl -I -H 'Authorization: Bearer fake' \
https://mastodon.bsd.cafe/api/v1/timelines/home
X-Cache-Status: BYPASS. If they do not, the skip-cache rules are wrong, and the entire setup is unsafe.If you intend to enable AUTHORIZED_FETCH, the third verification is for signed GETs. A quick synthetic check that the nginx map fires correctly:
curl -I -H 'Signature: fake' \If you added
-H 'Accept: application/activity+json' \
https://mastodon.bsd.cafe/users/someuser
$skip_cache_signature, the result should be X-Cache-Status: BYPASS.Finally, the logs themselves tell me how the cache is performing in production. Cache status distribution:
awk '{
for (i = 1; i <= NF; i++)
if ($i ~ /^cache=/) c[$i]++
}
END {
for (k in c) print k, c[k]
}' /var/log/nginx/access.mastodon.bsd.cafe.log
A healthy instance shows cache=HIT and cache=BYPASS doing most of the work, with cache=MISS accounting for cold paths and short-TTL refreshes. The same trick works for the variant distribution:awk '{
for (i = 1; i <= NF; i++)
if ($i ~ /^variant=/) v[$i]++
}
END {
for (k in v) print k, v[k]
}' /var/log/nginx/access.mastodon.bsd.cafe.log
This tells me what my traffic actually looks like. A federation-heavy instance shows a lot of activitypub. An instance with many human visitors shows more html. On mastodon.bsd.cafe the balance shifts depending on what is happening in the wider Fediverse on any given day.Short TTLs cost CPU. A 10-second microcache on a sustained-traffic URL means six backend regenerations per minute. That is much better than no cache, but it is not free. If the backend cannot comfortably handle that, raise the TTL or enable stale-while-revalidate on the dynamic paths.
Dynamic stale-while-revalidate is powerful but it hides problems. I currently keep proxy_cache_use_stale off on the dynamic locations because I am still validating behaviour. In steady-state production, stale-while-revalidate is usually the right choice. During rollout, it can quietly hide upstream errors and make debugging harder. Be honest with yourself about which mode you are in.
AUTHORIZED_FETCH changes the threat model. With secure mode disabled, public ActivityPub GET responses are safe to cache as public content, provided your cache key handles content negotiation correctly. With secure mode enabled, ActivityPub responses can become actor-dependent. At that point you must either bypass cache for signed GETs or include the signing actor in the key. The latter usually destroys the hit ratio, so bypassing is the practical answer.
The variant map is a compromise. It covers application/activity+json, application/ld+json, application/json, and text/html. Everything else falls into the default bucket. That is intentional, but the default bucket is still a bucket. If you discover a real client type that matters on your instance, add it explicitly.
Ignoring Vary is a responsibility. proxy_ignore_headers Vary is not magic; it tells nginx to stop protecting you based on upstream Vary. That is fine only if your own cache key and request normalization cover every dimension Vary was protecting. For this configuration that means normalizing Accept into a variant, avoiding backend Accept-Encodingvariation, never caching cookies or authorization, and never caching signed GETs if secure mode is enabled.
Followers and following are uncached on purpose. They are pagination-heavy and change frequently. Caching them would create many low-value entries with questionable freshness. If a remote instance hammers these endpoints, use limit_req_zone. Do not retrofit cache as a rate limiter.
Signed-URL redirects require shorter TTLs. Caching 302s is useful when redirects are stable. It is dangerous when redirects point to short-lived signed URLs. If your media storage returns presigned URLs, your nginx redirect TTL must be shorter than the URL lifetime.
Set-Cookie must remain special. Do not add Set-Cookie to proxy_ignore_headers unless you are absolutely sure the location cannot produce user-specific responses. nginx's default refusal to cache Set-Cookie responses is a safety net. Keep it.
A good configuration is a written form of the assumptions behind a service. When the assumptions change, the configuration must change too.
There is no single brilliant directive in this configuration. The trick is combining long TTLs for immutable assets, medium TTLs for media, tiny TTLs for dynamic public pages, cache locking for thundering-herd protection, strict bypass rules for private or actor-dependent traffic, a normalized content-negotiation key, and enough logging to prove the system is doing what I think it is.
What this layer buys me, in one sentence: fewer requests reach Puma and Rails.
That is the metric I care about. Mastodon is not slow, but it is heavy, and the bigger the instance grows the more it benefits from a layer in front that quietly absorbs the work that does not need to be done by the application. A reverse proxy that caches Mastodon safely has to remember, with every request, that the same URL might mean three different things to three different clients. Once it does, even a very short microcache can remove a surprising amount of load without changing the user-visible behaviour of the instance.
https://it-notes.dragas.net/2026/06/05/aggressive_caching_for_a_mastodon_reverse_proxy/
#ITNotes #NoteHUB #fediverse #hosting #mastodon #networking #nginx #ownyourdata #server #snac2 #social #web
An alle anderen: Ich freue mich riesig über einen Boost für die Reichweite, damit wir die Jungs an den Töpfen auch finden!
#gaychef #gastronomie #köche #queerchef #gaygermany #gaydach #lgbtq #fediverse #signal #berufskoch #profikoch #chefslife #küchenchef #schwul #gaybavaria #gaynetwork #queer #fedidach #mastodondach #gastro #kochen #schwuleköche
3/3
🛡️ #Cybersecurity news & tips across the #fediverse
“https:// m.youtube.com/watch?v=rwhznrpg l7k # Mullvad # Surveillance # Censorship # tech”
https://kolektiva.social/@Antisap/116825208666715780
🤖 via RSS feed. Not an endorsement.
s » 💀 🌐
@s@privacysafe.social
Good morning 🌞 fediverse and friends. Hope everyone has a wonderful day today.
Hey #musicproducers I have some things I want to release but I feel concerned about LLM's scraping my voice for their training. Does any one know of something I could use to overlay with my voice that would create dirty data for LLM's but that would keep the listening clear for human ears?
Please boost for visibility #music #producer #MusicProducer #musicproduction #dirtydata #mastodon #fediverse #help #programmer #llms #ai #airesearch #newtech
🛡️ #Cybersecurity news & tips across the #fediverse
“We Can Still Stop # California ’s # 3DPrinter # Surveillance Scheme https://www. eff.org/deeplinks/2026/06/we-c an-still-stop-californias-3d-printer-surveillance-scheme # privacy # AB2047”
https://mastodon.thenewoil.org/@thenewoil/116822664940319604
🤖 via RSS feed. Not an endorsement.
Es kann einfach nicht gut gehen!
Moin #Fediverse und euch einen gesunden Start in diesen Sonntag.
In den letzten Wochen habe ich in der Bau- und KI-Investment Szene recherchiert und meine Ergebnisse nun hier 👉https://www.metacheles.de/ki-blase-durchgerechnet-erst-zahlen-dann-erschrecken/ veroeffentlicht.
Es ist die mit Abstand groesste Spekulationsblase der Menschheitsgeschichte & ihr seid alle betroffen, denn eure Altersvorsorgen haengen mit drin!
Wuerde mich sehr freuen, wenn ihr diesen Post boosten koenntet.
Vielen Dank fuer den Support 🙏
Behavior in socio-technical systems, such as the #Fediverse, are created structurally by the architecture of that system.
The moralizing of individual behavior that emerges from structural problems is very much the same as "carbon footprint", even if the larger sociotechnical framework is different.
All sociotechnical systems exist with cybernetic feedback from the users, and the less adaptable the technology is, the more adaptable the users will become.
Both shitty bots and dogpiling behavior exist because the sociotechnical environment creates the dynamic.
Happy #SilentSunday, friends of #BSDCafe, #illumosCafe, and the whole #Fediverse!
May the peace of this view bring calm to this day.
Alone or in good company, that bench is there for you.
🛡️ #Cybersecurity news & tips across the #fediverse
“RE: https:// mastodon.xyz/@rms/116821811483 092534 Google data = State data Don't give the # fascists more ammo. De-Google today! https:// knurdology.com/indigenize-medi a/ # BigTech # resist #...”
https://kolektiva.social/@rootschange/116822564886245264
🤖 via RSS feed. Not an endorsement.
🥵 🏆 Warnwarnung vom 27.06.2026, 21:02 Uhr für die deutschsprachige Timeline:
❗ Amtliche WARNUNG vor AMTLICHEN WARNUNG
Gültig bis: wirklich alle gewarnt sind
Auf der Timeline ist mit einer HÄUFUNG von WARNUNGEN über AMTLICHE WARNUNGEN zu rechnen.
warnung.bund.de/meldungen
RE: https://toot.fedilab.app/@apps/116722285369696704
The most common answer is people asking what #HolosDiscover is. It's a service that indexes messages across the #Fediverse and lets you search through the data. What makes HolosDiscover unique is that it's not a scraper. It has an account, several opt-outs that automatically remove data, and most importantly indexed messages are immediately removed or updated as soon as the owner makes a change.
Have a look at https://discover.holos.social
🛡️ #Cybersecurity news & tips across the #fediverse
“Just when you thought # ChatControl was under control. Then someone decides to spin the wheel once more. https:// fightchatcontrol.eu/ # eu # privacy # surveillance”
https://infosec.exchange/@dazo/116821986677833261
🤖 via RSS feed. Not an endorsement.
🛡️ #Cybersecurity news & tips across the #fediverse
“SHUT DOWN UK’s MINISTRY OF TRUTH # BigBrother Watch’s investigation revealed that # secretive # UK # government # disinformation units have been # spying on # political # dissent and suppressing ...”
https://mastodon.scot/@paka/116821902006485652
🤖 via RSS feed. Not an endorsement.
Laut https://fedidb.com/servers ist #tagspub bereits die viertgrößte Instanz im #fediverse.
Wie lange bis es die zweitgrößte ist nach Mastodon.social oder sogar Platz Eins?
Mal abgesehen davon dass das ein Haufen Leute erstmal mit Benachrichtigungen abfuckt, sie rausfinden müssen was da passiert und wie man das abstellt, was bedeutet es für des fediverse, wenn es als Netzwerk mit hunderttausenden Bots wahrgenommen wird? Als Außenstehender versteht man das ja erst Recht nicht.
Is there a way to disable auto-boost of titles watched on NeoDB? I linked my Mastodon account to my NeoDB account and everytime I list some titles as “completed” my post is automatically boosted by the linked Mastodon account.
Is there a way to disable this function?
Thank you!
🛡️ #Cybersecurity news & tips across the #fediverse
“we had a lovely show yesterday with many bremen friends cheering for us. looking forward to tonight's show at kulturpavillion hannover!
now with special offer: bring a friend for 1/2 price 🦈🦈
https://pavillo...”
https://pixey.org/p/Ultramorbidi/976400880188579646
🤖 via RSS feed. Not an endorsement.
#Fediverse
I checked 4160 fediverse instances for their connectivity.
- A / AAAA record persent
- Reachabliltiy over #IPv6 if AAAA present.
107 Instances announce AAAA records but have broken inbound IPv6
2141 are #DualStack and have working inbound #IPv6
Way to go.
🛡️ #Cybersecurity news & tips across the #fediverse
“The WSJ exposes how tech extracts wealth from the masses via fake narratives. This completely demystifies the Western AI myth: it’s not a decentralized productivity engine—working-class wages have been stagnant since the...”
https://mastodon.social/@2k115/116820958713649732
🤖 via RSS feed. Not an endorsement.
@mullvadnet trying to gaslight the #Fediverse about "free speech" and fascism, and posting the same obviously PR-approved response to multiple negative posts about their co-CEO / co-founder donating money to fascists sure is a choice.
Barbara Streisand must be rolling in her grave.
How much of the fediverse magic is just that we opted in? No algorithm feeding us what's popular — we chose who to follow, what to see, and when to engage. That intentionality changes everything. #Fediverse #DecentralizedWeb
Bin gerade sehr verliebt ins #fediverse Mein erster Post von meinem neuen Betriebssystem - Linux Mint, dank Hilfe der community. #fedihelp #fedigive #did #dutgemacht #diday #linux
special thanks @karhima
https://swiss.social/@sonniandl_unterwegs/116821902262768718
Seit Wochen wurschtel ich rum um auf HP spectre von W11 auf Linux umzusatteln. Beim booten von USB FM die ich als Dummy nicht verstehe. Z.B. (Pop_OS) SBAT self check failed: security policy Violation, oder (Mint) failed ... \EFI\BOOT\mmx64.. not found, MokManager: not found, import_mok_state() failed...
habe jetzt Secure boot und Datenverschlüss. deactiviert. Neu,Ventoy Stick installiert, iso drauf,von Stick booten: Was ist MOK, was tun? Forensuche noch nicht hilfreich. #fedihelp #linux
🔆 #FediTips for https://PrivacySafe.Social & the #fediverse
“I've made a couple of posters to promote the Fediverse, perhaps on community noticeboards, or at activist or tech events etc. I've left part of the posters blank so you can customise them with sources of info about the ...”
https://social.growyourown.services/@FediTips/116823039153949219
🤖 via RSS feed. Your Mileage May Vary.
Wrote up why lighthouse.co.im finally moved from bare metal to Docker Compose -- and why it took a toot from @adamhavelka to make me look at my own setup properly.
The short version: the bare metal wasn't ideology, it was Certbot trauma. Caddy fixed the actual problem.
One database migration did not survive the journey. Now documented so you don't have to rediscover it.
https://haunted.lighthouse.co.im/articles/bare-metal-to-docker/
#Mastodon #SelfHosting #Docker #Fediverse #AdminLife
I've made a couple of posters to promote the Fediverse, perhaps on community noticeboards, or at activist or tech events etc.
I've left part of the posters blank so you can customise them with sources of info about the Fediverse (for example useful websites, local user groups, local/national servers to join etc).
You can find the posters (and lots of questions answered) at:
➡️ https://fedi.tips/posters-for-promoting-the-fediverse
Also, any feedback, translations or alternative posters very welcome!
🛡️ #Cybersecurity news & tips across the #fediverse
“To defend against hybrid attacks, governments should team up with the private sector https://www.politico.eu/article/hybrid-attacks-governments-team-up-private-sector/?utm_source=RSS_Feed&utm_medium=RSS&utm_campaign=RSS...”
https://social.espeweb.net/objects/f75e81ab-7ce9-4a3f-9369-ff0501ba15bc
🤖 via RSS feed. Not an endorsement.
Trying to see where things are with FEP-ef61: Portable Objects. Anyone working on this?
https://fediverse.codeberg.page/fep/fep/ef61/
https://socialhub.activitypub.rocks/t/fep-ef61-portable-objects/3738
Years ago I built a People Directory for the fediverse, to help you find people based on topics aka hashtags in their bio.
Spread the word!
RE: https://mastodon.social/@dansup/116822734968898442
I'm thinking a federated wiki type service with a trust metric that allows more trusted users to moderate/curate edits.
We could expand this beyond related hashtags.
#activitypub #fediverse #pixelfed #askfedi
🛡️ #Cybersecurity news & tips across the #fediverse
“Karma is coming. Quote from Wikileaks: Prominent US war hawk John Bolton has pled guilty to violating the Espionage Act after previously demanding execution for whistleblowers Edward Snowden & Chelsea Manning and 176 y...”
https://infosec.exchange/@AmmarSpaces/116819321092938488
🤖 via RSS feed. Not an endorsement.
🛡️ #Cybersecurity news & tips across the #fediverse
“# EFF , # TEDIC and # CEJIL Challenge Secrecy in the Use of Face Recognition in # Paraguay https://www. eff.org/deeplinks/2026/06/eff- tedic-and-cejil-challenge-secrecy-use-face-recognition-paraguay # ...”
https://mastodon.thenewoil.org/@thenewoil/116818300132627657
🤖 via RSS feed. Not an endorsement.
Hey #KommunenAmLimit - hier habt ihr eine #mastowall
https://rstockm.github.io/mastowall/?hashtags=KommunenAmLimit&server=https%3A%2F%2Fmastodon.social
Der Hashtag zeigt ganz gut, dass man mittlerweile auch im #fediverse Kampagnen fahren kann.
🎉 The Fediverse is meeting IRL at FediCon.
Talks. Demos. Panels. Real humans.
🎟️ Get your FOSSY ticket, which gets you into FediCon ⬇️
https://2026.fossy.ca/attend/tickets/
🌐 FediCon
📍 UBC campus, Vancouver (Canada)
🗓️ August 6-9
Took a lil break from Pixelfed dev to update the fedicon.ca website, I hope @reiver approves and merges the PR!
https://dansup.github.io/fedicon-www/
It's much cleaner and informative, though it does need the final schedule and speakers.
I also added some logic to hide sections after certain dates 😎
🛡️ #Cybersecurity news & tips across the #fediverse
“@ WJCT @ jacksonville-today-WJCT If # pedo buddy # DeSantis was actually worried about government # surveillance , we wouldn't have # Flock cameras and # APRs everywhere. He's a sawed off, piece ...”
https://mastodon.social/@Bandersnatch/116818088853397546
🤖 via RSS feed. Not an endorsement.
In case you want to help us with the development (and we could really use your #frontend help right now, not gonna lie...) or you're just interested in dev side of things: join us on our new dev channel!
Ist es nicht ein bißchen arrogant, wenn wir hier im Fediverse etwas von "Stromverbrauch der KI RZ" schreiben und dabei im RZ daneben durch das Senden und Verteilen des toots Strom verbrauchen?
🛡️ #Cybersecurity news & tips across the #fediverse
“TikTok collects keystroke patterns, clipboard contents, and device identifiers beyond what most users realize when they agree to its terms. # privacy # tiktok # tracking # surveillance # indigoprivacy”
https://mastodon.social/@indigoprivacy/116817791667788983
🤖 via RSS feed. Not an endorsement.
🛡️ #Cybersecurity news & tips across the #fediverse
“Flock is expanding to collect SIGINT data harvested by Bluetooth sensors at traffic lights. At this point, it's making me sick seeing 5-10 devices hanging from almost every traffic light. This technology would allow ALP...”
https://infosec.exchange/@sethhonda/116817498990434675
🤖 via RSS feed. Not an endorsement.
Week in Fediverse 2026-06-26
Servers
- Vernissage Server v1.39.0
- Bookwyrm v0.9.0
- Mastodon v4.6.1
- GoToSocial v0.21.3
- Ktistec v3.6.0
- snac v2.93
- Mitra v5.6.0
- Misskey v2026.6.0
- NeoDB v0.16.2.1
Clients
- Fedilab v3.42.0
- Mastodon for Android v2.13.0
- Voyager 2.47.3
- Tesseract v1.5.4
- Holos v1.10.2
- Phanpy changelog
- Rocinante: A modern, open-source Android client for BookWyrm
For developers
- Fedify v2.3.0
- Masto.js v7.12.0
Articles
- FR#168 – LLMs Join The Fediverse
-----
#WeekInFediverse #Fediverse #ActivityPub
Previous edition: https://mitra.social/objects/019ee1be-dd85-7353-beca-83c9a087b4fc
RE: https://stefanbohacek.online/@stefan/116817281859547761
Every now and then I see people getting really upset when features change, break, or are missing.
Let this be your occasional reminder that the fediverse is run by regular people like you and me, who are doing their best with very limited resources.
I get being frustrated, but use that energy to file a bug report, maybe even offer help, if you have the skills. Or donate, if you can afford it.
We make the fediverse better by working together.
PDX.social is a Mastodon server for the Portland, Oregon, USA region.
This server has been online since 2017.
You can find out more at https://pdx.social/about or contact the admin account @admins
#FeaturedServer #Portland #Oregon #PortlandOR #USA #Mastodon #Fediverse #FreeFediverse
My fediverse invitation page creator now supports Collections!
Give it a try: https://stefanbohacek.com/project/fediverse-invitation/#link-builder
RE: https://mastodon.social/@cheeaun/116777616644053403
Heads-up, you might want to check if your favorite app supports this, and let the developers know if not.
(Just reached out to the folks making the Mona app.)
The good, the bad, and the ugly of running a fediverse server for the past four years, from @gfsc.
"Rather than getting mad at Bluesky for taking over the debate, the fediverse needs to look at itself and ask who it’s including, who it’s excluding, and how it can actually become a transformative social network, rather than a technological toy for computer programmers."
https://gfsc.community/why-we-discontinued-our-mastodon-server/
Summer is here, and sadly it is peak season for pet abandonment.
#PawFed is a federated map for animal welfare built on #ActivityPub and #OSM.
It already shows shelters and vets near you. Found an abandoned animal or need help? Mention @PawFed from any #Fediverse account: a pin lands on the map, and your call is relayed across the #Fediverse, whatever your instance.
Please enjoy these animated 88x31 fediverse GIFs!
Dark: https://static.stefanbohacek.com/88x31/fediverse/fediverse-88x31-dark.gif
Dark with border: https://static.stefanbohacek.com/88x31/fediverse/fediverse-88x31-dark-border.gif
Light: https://static.stefanbohacek.com/88x31/fediverse/fediverse-88x31-light.gif
Light with border: https://static.stefanbohacek.com/88x31/fediverse/fediverse-88x31-light-border.gif
Two things you can see here... It's pretty hot! That's why I stayed home and implemented a missing feature into snac. That's what you can also see - it finally sends push notifications to devices! In this case, we can see notifications coming from #MastoBlaster App for iPhone.
What we can also see, it's still a bit faulty and not the expected content, but a first success here at least ;) I'll make some further adjustments when there's time and get in touch with @grunfink@comam.es to check if we can get this upstream. Thanks to @stefano@bsd.cafe for testing with me :)
#fediverse #mastodon #fedi #activitypub #snac2 #c #programming #clang #MastoBlaster
Dear Fedi friends,
I'm really proud to share with you a video I made: "Introducing the Fediverse: a New Era of Social Media" https://news.elenarossini.com/fediverse-video/
In this 4-minute video I explain what the #fediverse is to people not familiar with it, mentioning some of its great features and benefits (interoperability, no ads, no surveillance...) and I set it in contrast to the world of Big Tech social platforms. I argue that, with the rise of Big Tech oligarchs and the current political climate, there has never been a better time to join the fediverse.
I hope you will enjoy this video and that you will find it useful (maybe as a tool to introduce your friends, family, colleagues, school administrators, local government officials to it).
The fediverse has truly changed my life, making me a better, more empowered digital citizen. I am endlessly grateful for it, so this is my contribution to the cause ❤️
I am also incredibly thankful for the work of @samaaberg and @patel.riyen who helped me bring my vision to life with their amazing cinematography skills and their assistance throughout the process, providing brilliant feedback to the script / edits from the POV of fedi newbies.
And I was also moved by the generous help of people of the Fediverse who volunteered to translate the script into many foreign languages: @jan @fritjof @erikkemp @sknob @severin @clabru @tarcisiosurdi @hongminhee @danielcasanueva @ainali @nacly
Lastly, I'm thankful for the opportunity I had to premiere the video last week at #FediForum - thank you @j12t and @anca
The video is up on my self-hosted PeerTube instance (thank you @yunohost) and for now it is unlisted as I have no idea how my VPS will hold up. I also included an alternate location in the blog post.
I hope you'll enjoy it! It's been a real labor of love (a month of full time work on it)... I see it as my love letter to the fediverse 💌
New: Last Week in #Fediverse - ep 91
This week's news:
- @loops has launched and is now available for everyone!
- @radiofreefedi will shut down early next year
- Bridgy Fed talks about potential governance directions
Read at: https://fediversereport.com/last-week-in-fediverse-ep-91/