Nostr notes by OldKid ⁂

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] But not ...

2026-06-05T12:55:21Z

In reply to nevent1q…3lek
_________________________

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] But not everyone collects data as aggressively as tags.pub. Or are you telling me that the 361,500 accounts on tags.pub are just dormant?

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] See my ...

2026-06-05T11:51:14Z

In reply to nevent1q…c83w
_________________________

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] See my post a little further up; it’s also about the legal aspect. However, other platforms don’t make it that easy for people to filter out individuals using specific hashtags and then use that data for purposes such as harassment.

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] ...

2026-06-05T11:39:43Z

In reply to nevent1q…z32m
_________________________

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] @[url=https://burningboard.net/ap/users/115674483682152158]Jörg 🇩🇪🇬🇧🇪🇺[/url] OK, just to make sure I’ve got this right. If, as an admin, I add tags.pub to my instance-wide block list, will posts from users on my instance no longer be shared? How is that supposed to work if tags.pub can still receive posts via other relays?

I’m asking because, as an admin here in the EU/DE, I have a problem with this, as posts containing personal data requiring special protection under Article 9 of the GDPR – such as health (e.g. illness hashtags), sexual orientation, political opinion, or religious or philosophical beliefs – are shared via tags.pub without the users’ knowledge.

According to Article 9, there is a general prohibition on processing such data, subject to authorisation; in most cases, explicit consent is required.

Even if one were to argue that the user, by publishing their post, has consented to this, it is legally questionable whether a single public post truly means that the person consciously and comprehensively intended to make the sensitive information public – and whether this justifies the subsequent aggregation and amplification – is a matter of debate. There is a risk here, as aggregation facilitates outing, harassment and profiling.

So, as admins, we find ourselves in quite a quandary if we allow this to happen without further ado.

Nostr event nevent1qqs2yh57r49fwwmv5ry529a8w7kwfvf8x4n00ta9amlhcpc3jvfyx2czyptgze2xc6uls7kpv4l2ud2jxmeadqjfxrfevvq785tej0n5n09p293lvek

2026-06-05T06:45:26Z

In reply to nevent1q…gw3k
_________________________

@[url=https://toot.berlin/users/blindcoder]Benjamin[/url] @[url=https://anonsys.net/profile/tux]Tuxi ⁂[/url] der AP traffic von tags.pub ist nicht das Problem. Sondern der AP Traffic der durch den boost entstehen kann. Ich habe das mal für eine kleine Instanz durchrechnen lassen. Das kommt dabei zusammengefasst raus.
[h2]Besondere Risiken für kleine und ressourcenschwache Instanzen[/h2]
Gerade kleine Server (oft Hobby-Betrieb mit einem Admin, schwacher Hardware, wenig Bandbreite) trifft tags.pub am härtesten:
[ul]
[li][strong]Lastspitzen durch Verstärkung (Fan-out):[/strong] Sobald tags.pub einen Beitrag boostet, geht dieser Boost an [em]alle[/em] Follower des Hashtag-Kontos. Jede dieser teils hunderten oder tausenden Empfänger-Instanzen ruft daraufhin den Originalbeitrag, das Autorenprofil und enthaltene Medien direkt von deiner kleinen Instanz ab – schlagartig und gleichzeitig. Dieser „Hug of Death"-Effekt kann einen schwachen Server unter der plötzlichen Anfragelast in die Knie zwingen.[/li]
[li][strong]Zusätzliche Abruflast durch tags.pub selbst:[/strong] tags.pub cacht fremde Inhalte nur kurz und ruft sie danach erneut ab – wiederkehrende Anfragen, die bei aktiven Hashtags spürbar werden.[/li]
[li][strong]Ungewollte Reichweite und Moderationslast:[/strong] Ein Beitrag, der für eine kleine Community gedacht war (aber technisch öffentlich ist), wird unvermittelt netzwerkweit verteilt. Das kann Trolle, Spam oder Belästigung auf eine Instanz lenken, die weder die Moderationskapazität noch die Werkzeuge hat, damit umzugehen.[/li]
[li][strong]Kaum wirksame Gegenwehr:[/strong] Genau diese Instanzen haben am wenigsten Mittel, sich zu schützen – ein Block kostet Last, ohne die Verbreitung zu stoppen, und sabotiert obendrein das [code]#NoBot[/code]-Opt-out.[/li]
[li][strong]Kontrollverlust bei Löschungen:[/strong] Löscht ein Nutzer seinen Beitrag, muss die Löschmeldung tags.pub erreichen, damit der Boost zurückgenommen wird. Ist die Instanz gerade nicht erreichbar (oder blockiert), bleibt der Boost mit einem toten Link bestehen.[/li]
[/ul]

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] ...

2026-06-05T05:48:55Z

In reply to nevent1q…3td5
_________________________

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] @[url=https://burningboard.net/ap/users/115674483682152158]Jörg 🇩🇪🇬🇧🇪🇺[/url] But if I block the domain as an admin – i.e. across the entire instance – does that not work?

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] Yes, ...

2026-06-05T05:46:31Z

In reply to nevent1q…u267
_________________________

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] Yes, and furthermore, the administrator of an instance should be able to prevent a relay with which the instance has no direct connection from sharing posts by users of their instance.

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] ...

2026-06-04T06:21:23Z

In reply to nevent1q…cjz9
_________________________

@[url=https://cosocial.ca/users/evan]Evan Prodromou[/url] @[url=https://burningboard.net/ap/users/115674483682152158]Jörg 🇩🇪🇬🇧🇪🇺[/url] doch klar ist das möglich da der Block nur lokal wirkt aber nicht, wenn Beiträge über ein Relay verteilt werden.

[quote]Ein Domain-Block auf deiner Friendica-Instanz ist gegen tags.pub kein zuverlässiger Schutz. Der Grund liegt darin, [em]wie[/em] der Code an deine Beiträge kommt.
[h2]Wie tags.pub an deine Beiträge gelangt[/h2]
tags.pub bekommt deine öffentlichen Posts nicht nur direkt von dir. Aus dem Code ([url=lib/bots.js]bots.js[/url], [url=lib/tagbotfactory.js]tagbotfactory.js[/url]) ergeben sich drei Wege:
[ol]
[li][strong]Direkte Zustellung[/strong] — z. B. wenn jemand bei dir [code]_followback@tags.pub[/code] folgt; der Bot folgt zurück, und deine Instanz stellt die Posts dann direkt an die tags.pub-Inbox zu.[/li]
[li][strong]Über Relays[/strong] — [code]RelayClientBot[/code] abonniert Relays ([code]RELAYS[/code] env). Kommt ein Beitrag als [code]Announce[/code] von einem Relay, das auf der [code]announceAllowList[/code] steht, verarbeitet ihn [code]#handleAnnounce[/code] ([url=lib/tagbotfactory.js]tagbotfactory.js:240[/url]).[/li]
[li][strong]Über Boosts/Weiterleitungen dritter Instanzen[/strong], die wiederum an Relays hängen.[/li]
[/ol]
Dein Domain-Block wirkt [strong]nur lokal auf deiner Instanz[/strong]. Er unterbricht Weg 1 (den direkten Kanal zwischen dir und tags.pub). Auf Weg 2 und 3 geht dein öffentlicher Beitrag aber zuerst an einen [strong]Relay-Server oder eine andere Instanz[/strong] (jeweils eine [em]andere[/em] Domain, die du nicht geblockt hast) — und von dort holt sich tags.pub den Beitrag. tags.pub läuft nicht auf deiner Infrastruktur; was es von Dritten bekommt, kannst du mit einem lokalen Block nicht verhindern.

→ Sobald deine Instanz an ein Relay published (oder Drittinstanzen deine Posts weiterverbreiten), das tags.pub abonniert, wird weiter geteilt.[/quote]