Zum Thema #nostr: Da bin ich letzte Woche in einen sehr tiefen Kaninchenbau gerutscht. Zunächst, ich verstehe, warum nostr als interessantes Konzept wahrgenommen wird: dezentrale Kommunikation und keine Serverabhängigkeit der eigenen Identität und vor allem "Zensurresistenz". Aber genau hier liegt für mich das Problem – technische Freiheit allein reicht nicht aus, wenn soziale Verantwortung fehlt.

Was mich zunächst skeptisch gemacht hat:

• 
  [li] Starke Bitcoin-Verknüpfung: Nostr ist eng mit der Bitcoin-Szene verwoben, wo oft eine Ideologie von maximaler Unreguliertheit vorherrscht. Dezentralität ist gut, aber wenn sie vor allem genutzt wird, um jegliche Moderation als „Zensur“ zu framen, frage ich mich, welche Art von Community dabei entsteht.
  [li] Absolute „Zensurresistenz“ bedeutet auch Schutz für toxische Akteure: Ein System, das sich damit rühmt, „nicht regulierbar“ zu sein, wird zwangsläufig von denen genutzt, die anderswo keinen Platz finden – nicht nur Dissidenten, sondern auch Gruppen mit fragwürdigen Absichten.

Aber in den besagten Kaninchenbau rutschte ich bei Recherche zu einer Person, die dort eine zentrale Rolle spiel:
Alex Gleason (ehemals Pleroma (1), nun Soapbox, JoinTheFedi) ist eine treibende Kraft hinter Nostr und hat bereits im Fediverse durch Spaltungen, Falschdarstellungen und feindseliges Verhalten Aufmerksamkeit erregt. Das lässt mich daran zweifeln, dass es bei nostr und den Applikationen wirklich um eine nachhaltige, diverse Alternative geht.

Ich habe mir dann mal JoinTheFedi.com angeschaut – eine Seite, die das Fediverse angeblich „neulingsfreundlich“ erklärt. Dabei ist mir aufgefallen, dass dort ausschließlich Instanzen aus dem Umfeld von Alex Gleason beworben werden, u. a. poa.st, Spinster.xyz und Freespeechextremist.com. Besonders kurios: Poa.st (von vielen DE AP Server gebannt wegen Hate Speech) wird als „größte Instanz im Fediverse“ bezeichnet – obwohl allein Mastodon.social zehnmal mehr Nutzer hat.
Das sind alles Seiten mit einer extremen "free" speech Ideologie.

Ich bin für Dezentralität mit Verantwortung. ActivityPub hat viele Schwächen, aber es bietet etwas, das Nostr nicht hat: die Möglichkeit zur gemeinschaftlichen Selbstregulierung. Eine dezentrale Struktur muss nicht chaotisch oder unkontrolliert sein – sie kann auch ein System von regionalen, vertrauenswürdigen Instanzen sein, die Offenheit und Schutz vereinen.

(1):
https://hacktivis.me/articles/Update%20on%20Pleroma%20Maintainance

Итак, сегодня настроил еще один бридж из #Telegram в #Fediverse (огромный респект #mastogram), восстановил кошелек в Wallet of Satoshi, и заодно нашел кучу материала, который можно задействовать в моих активностях на #Nostr.

Главное не лениться.

#blog

#globalswitchday Check: securemessagingapps.com rate 🟩=3 🟨=1 🟥=0 = 86 Threema = most secure #Messenger 81 #SimpleXChat80 #Signal77 #Session68 #Wire61 #Wickr #Amazon56 #Element / #Matrix37 #Apple #iMessage32 #WhatsApp27 #Telegram26 #Facebook Messenger 10 #Microsoft #Skype#X -> #nostr

@pixelfed Work with #Damus . A #Nostr Protocal. It’s completely decentralized. It’s basically like #Mastodon but with no instances like #Blusky. That’s the only flaw, the only problem is the Sign-In/Log-Ins. Just use username and 𝘝𝘰𝘪𝘭à. It would be a great Pro if #Pixelfed would use that direction and not collect E-Mail a Password. I’d wish #Pixelfed will go to that route.

Basically, it’s the Sign-In/Log-in. That bothers me. Please make it easy.

the app works like a local email client, you are not sending your email address to any 3rd party server, it is similar to using #Thunderbird, that said, you don't need to use your #email address, you can login anonymously using #chatmail servers that basically provide you similar advantages to #Nostr and #Session

For those using a self-hosted Alby Hub that hosts their Lightning Network Wallet to send/receive sats on the Nostr network, it is crucial that the connected wallet stays online. If not, the user cannot make or receive any sats.

I’ve noticed twice already that my wallet was offline, only about a day later. It seems that whenever my server has been rebooted, or the Alby Hub container is restarted after an update, that the Alby Hub requires a login again just to reactivate the wallet connection. All you have to do is go to the URL for your Alby Hub and type in that password, then everything is active again.

My problem though was, I was using my own self-hosted Uptime Kuma to alert me if my Alby Hub was offline. But if the container was restarted the Alby Hub page showed as online, and this alert only worked if the whole server was down or the container did not restart. It did nothing for Alby Hub being online, but not logged in.

I did determine earlier on that the indicator that showed if the Alby Hub wallet was online and logged in, would change the balance attribute to show either the sats balance as a number (logged in), or it changed the balance value to null if it was not logged in. If you have activated your access token on the Get Alby site at https://getalby.com/developer/access_tokens/new for balance:read, you can easliy run the following command from the terminal to read that data: curl https://api.getalby.com/balance -H [strong]"[/strong]Authorization: Bearer access_code[strong]"[/strong] where you replace access_code with your own access code. This will return some JSON code, and you will see a value for balance that either shows your actual sats balance, or it will show null.

So my multi-hour challenge today was to try to get Uptime Kuma to read that balance and if it was a value above 0 then consider the wallet online, but if it showed a null value, then send an alert to say it is offline.

My struggle was to get the returned value correctly evaluated in Uptime Kuma’s rather simplistic JSON evaluation field. The null value was also throwing out issues as you can’t use the number() function to convert a null value (it gave an error) and this was obscuring the logic I was trying to test.

In the end, the parts of it that worked in Uptime Kuma were (see post’s featured image):

• Monitor Type: HTTP(s) - Json Query
  
• URL: https://api.getalby.com/balance
  
• HTTP Method: GET
  
• HTTP Body Encoding: JSON
  
• HTTP Body: {"balance": "application/json"} — this gets the value of balance
  
• HTTP Headers: {"Authorization": "Bearer access_code"} – this is used to authorise access to query the balance value
  
• Json query: balance != null ? 1 : 0 — checks if balance is not null, and if not then return 1, but if balance is null then return 0
  
• Expected value: 1 — balance is expected to be 1 if all is fine

The crucial parts are the test statement in the JSON query field compared to the Expected value field. If the query matches 1 then all is fine and there is no alert, but if the query changes to 0 then an alert is triggered.
#Blog, #albyhub, #Nostr, #technology, #uptimekuma

I wish @TheAdmin would block #Nostr as best it could. It is routinely, abuse.

I'm starting to get hyped for #nostr.
Therefore, I'm searching for criticism of nostr. Does someone have nice blog posts/rants about nostr criticizing the hell out of it? (But please not based on "I don't like the people building it", just based on the merits and disadvantages of the protocol)