The OP_RETURN "debate" of the bitcoin "community" is an excellent demonstration for why X is an abysmal neutral ground as a public square.
Râu Cao ⚡
raucao@kosmos.org
npub1raus...dees
Traveling full-time since 2010. Working on open-source software daily. Currently integrating Nostr features into Kosmos accounts.
@Alex Gleason Any chance you could have a look for why my posts don't get published by mostr on fedi anymore? I'm sure there must be more accounts if it's happening with mine. Last published one (or at least the last one ending up on my instance) was in January this year...
(I'm broadcasting all my stuff to the mostr relay, so that's not it.)
Bitcoin will definitely die, because of a change in bitcoin core that doesn't change consensus rules!
One more death for 

Bitcoin Is Dead
Bitcoin Is Dead - Track Every Bitcoin Obituary Since 2010
Bitcoin Is Dead tracks 464 bitcoin obituaries since 2010. See how many times Bitcoin has been declared dead by critics and media, with the complete...
Not sure if I did this right, but I'm accepting issues and PRs for the Nostr Links extension via Nostr now:
Original repo here:

GitWorkshop.dev
Decentralized github alternative over Nostr
Gitea
nostr-links
A web extension to discover Nostr links
Just a note on CI solutions:
For
we use Gitea Actions, which is compatible with GitHub Actions, like you describe.
It works nicely, and the configuration allows to configure both hosted and external runners per repo, user, or org. (Meaning you don't have to allow just any user to run arbitrary payloads on your infra, but you can allow only trusted or paying users to do it.)
Being compatible with GitHub Actions brings baggage, but also convenience and less migration work, of course.

Gitea
Gitea
Gitea (Git with a cup of tea) is a painless self-hosted Git service written in Go
Overview | Gitea Documentation
I also just added the link rel elements to my Atom feed. So if you have a feed reader with both RSS/Atom and Nostr support, and someone adds a URL for the former to your reader, it could now detect the Nostr alternative and offer the user to subscribe to that instead.
Also interesting if some of the feeds you're already subscribed to (maybe for much longer than Nostr even existed) started adding alternate Nostr links in the future, so we could slowly migrate to a more decentralized system.
Maybe something for noflux, @fiatjaf?
View quoted note →
Turns out that @fiatjaf fixed the issue with the commas a while ago. So if you just use the latest version of nak with this, then all is good. 🥳
View quoted note →
Apparently, absolutely nobody wants to relay a zero-fee tx from my node. Where have all the plebs gone?
Who of you left this sticker on a a directional antenna on Carenero?


@fiatjaf Have you thought about NIP-23 feeds for publications instead of pubkeys?
I.e. one could subscribe to a feed of a specific blog that multiple authors write using their own pubkeys. Most blogs in my RSS reader work like this, and I think it's crucial for NIP-23 to be as useful as it can be. The cool thing about Nostr feeds vs normal RSS feeds is that the content would be properly attributed to each author and can be gathered and rendered outside of a centralized blog/feed as well.
I was thinking about creating a new kind for announcing a "publication" (i.e. blog, magazine, etc.), which holds metadata similar to a kind 0 profile (display name, avatar/icon, description, ...). The pubkey "founding" the "publication" would then add tags for authorized author pubkeys, so clients could verify that when a kind 30024 article is tagged with one or more publication IDs, it's not spam or impersonation.
One problem with this (and with a system without time in general) is that when a founder would remove authors later on, it would appear as if they never wrote for a certain publication. But I'm not sure it's actually a problem in practice.
What do you think? Maybe I'm thinking about this all wrong? Or maybe someone has solved this already?
GM from wintery Bogotá.
Not far to @Hacker Beach now.


GM

