Nostr notes by pixelmind

I just learned Ditto also accepts xaps

2026-09-20T20:09:44Z

In reply to nevent1q…9rvz
_________________________

I just learned Ditto also accepts xaps

I was asking which nostr clients included XMR zaps. Apparently ...

2026-09-20T20:01:27Z

In reply to nevent1q…dkte
_________________________

I was asking which nostr clients included XMR zaps. Apparently only Amethist has this feature, but then some Primal users have managed to get XMR too. I guess I'll have to test it myself

I can try to explain 15 years of distro hopping in 1 line: want ...

2026-09-18T04:41:50Z

In reply to nevent1q…wwvz
_________________________

I can try to explain 15 years of distro hopping in 1 line: want the latest of the main software? Go fedora. A little more risk but the latest of everything? Arch. Want a stable OS with all the software, but don't care older versions of everything? Debian. Then the desktop environment, minimal is Gnome, but I use KDE. It's just a matter of taste

Which client let's you do this? I can't find a way to ...

2026-09-13T20:22:36Z

In reply to nevent1q…ds4l
_________________________

Which client let's you do this? I can't find a way to connect to my Monero wallet from Primal. I've read about Amethist being the only client to do so.

# Future-Proof Formats for Technical Content and Page Design ...

2026-09-07T10:30:39Z

# Future-Proof Formats for Technical Content and Page Design

I've been working on desktop publishing, design and technical documents since the early 80s, so you can imagine how many times I've lost and found old documents, a few happily recovered, but too often either corrupted or orphaned by obsolete software. Think of those spoiled TIFF images, or a QuarkXPress document you can no longer edit. This panic on document loss has kept me focused for years on future-proofing my work, or anyone else's document collection.

## Premise

With the previous context in mind, a format would qualify as future-proof only if it meets all of:

1. **Text-based or markup** — a plain-text serialization exists, even if a binary artifact is also produced (XML derivatives count).
2. **Documented standard** — a published specification ("white book") plus at least one conformant, independent implementation, so the format doesn't die with a single vendor.
3. **Single-binary preference** — a self-contained compiler/interpreter beats a modular toolchain with a package manager and transitive dependencies. Typst is preferred over LaTeX, Rust/Go tooling over Node/npm stacks.
4. **Graceful failure** — if the processor disappears, the *source* should still be readable and re-implementable by a human, not just re-parseable by another program. Considering this premise, we can see how Markdown degrades better than HTML; also Typst source degrades better than compiled SVG.

We are doing this study on three different layers:

* The **structured data** layer, which doesn't have a predefined order or composition
* The **authoring** layer, containing ordered information such as a sequential text with a semantic structure, or a specific graphic composition
* The deliverable or **layout** layer, including the previous parts, and the post-processing rules for print or electronic publishing.

While layers define the final purpose, or stages before delivery, territories define the nature or internal structure of documents. Each territory is owned by a chosen format, and this format belongs to its specific territory.

We're exposing our chosen formats in reverse layer hierarchy, starting from the layout formats. Chosen formats are not necessarily the best existing format, feature-wise or by any other specification, but the one qualifying best in the 4 previous rules.

## Layout formats

| Format | Spec / reference | Processor | Territory | Weak at | If the tool disappears |
|---|---|---|---|---|---|
| **Typst** | Typst's own published syntax reference + open compiler source | `typst` binary (Rust, single executable) | Typesetting, page layout, long-document structure with precise control | Free-form illustration; not a drawing tool | Source (`.typ`) is plain markup, readable and re-implementable; single implementation today is the main risk, mitigated by an open spec |
| **Scribus** | `.sla` is a documented XML schema | Scribus (Qt/C++, single app) | WYSIWYG desktop publishing, repetitive layouts (newsletters, forms, brochures) | Precise typesetting logic, programmatic/repeatable builds | `.sla` survives as XML even without Scribus, but re-editing without the GUI is hard — layout-by-coordinates isn't hand-writable the way Typst markup is |
| **SVG** | W3C SVG spec | Any conformant renderer (browsers, Inkscape, resvg, librsvg) | Standalone one-page deliverables where shape carries the layout — flyers, cards, stationery | Long text, running page layout, typographic control | Source is XML, human-legible, but hand-editing paths/transforms is impractical without a GUI |

**Typst.** Owns the document. Where LaTeX would traditionally sit, but compiled by a single Rust binary instead of a TeX distribution plus package manager. Strong at programmatic layout (templates, repeatable structure, citations, cross-references) with a syntax that's actually pleasant to hand-write and diff in git — which matters for the "legible if abandoned" criterion, since a `.typ` file is closer to Markdown-with-superpowers than to LaTeX's macro soup.

**Scribus.** Owns the case Typst is bad at: layouts driven by *placement*, not *flow* — a page where a photo, a pull-quote, and three text blocks all need to sit in exact visual relationships that don't derive from a logical document structure. That's a WYSIWYG problem, not a typesetting problem, and Typst deliberately doesn't try to solve it. Scribus is the right tool exactly because it's a canvas with frames rather than a compiler with a layout algorithm — but that means it can't be scripted/repeated as cleanly as Typst can for a document template.

**SVG / Inkscape.** Owns anything where shape, not text flow, is the content. Considering it a layout format, that would apply to flyers or one-page business documents (cards, stationery). It technically supports `<text>` and even multi-line flow via `<flowRoot>` (Inkscape-specific, non-standard), but there's no real notion of pagination, running headers, footnotes, or reflow — it's a canvas, not a document. Use it for the graphic, not the page. This format can both be considered in the deliverable or authoring layer, depending on the structure and scope of the overall design (see below).

## Authoring formats

| Format | Spec / reference | Processor | Territory | Weak at | If the tool disappears |
|---|---|---|---|---|---|
| **SVG** | W3C SVG spec | Any conformant renderer (browsers, Inkscape, resvg, librsvg) | A component feeding a larger document — diagrams, icons, illustration, logos meant to be embedded, not read on their own | Long text, running page layout, typographic control | Source is XML, human-legible, but hand-editing paths/transforms is impractical without a GUI |
| **Markdown** | CommonMark spec | Any of dozens of independent parsers | Authoring content and structure, when final design is outsourced elsewhere | No layout or typographic control at all — by design | Near-zero risk: it's already the most degraded, most legible state a document can be in |

**SVG / Inkscape, here.** The distinction from the layout-layer row above is the destination: a diagram or icon authored to be embedded in a Typst document or Scribus frame belongs here; a standalone one-page piece that *is* the finished deliverable belongs in the layout table.

**Markdown.** Owns the raw content — the writing itself — whenever the final visual form is somebody else's problem, or a later step in the pipeline. It's the natural interchange point: content gets written once in Markdown, then either compiled to a document via Typst (for typeset output) or hand-placed into Scribus frames (for WYSIWYG collateral), or converted straight to SVG-embedded text for illustration captions. \
Other excellent formats like reST and AsciiDoc are excluded by the same criteria that admit Markdown: equally legible, but their practical processing paths — Sphinx, Asciidoctor/Ruby — pull in exactly the modular-dependency weight rule 3 rules out. They're not disqualified on legibility; they're disqualified on toolchain weight.

## Decision guide

- **Is the deliverable a document meant to be read start to finish** (report, article, book, normativa)? → **Typst**.
- **Is the deliverable a fixed visual composition where position matters more than flow** (flyer, one-off form, repeated-template newsletter)? → **Scribus**.
- **Is the deliverable a standalone graphic, icon, or diagram**, with at most short embedded labels? → **SVG**.
- **Is this step just "write the content," with layout to be decided or outsourced later**? → **Markdown**, then route into one of the above.

## How they compose

Typst, Scribus, SVG, and Markdown span the layout and authoring layers above, and they aren't really competitors — they chain:

- **Markdown** (content) →
- **Typst** (layout/typeset) → PDF/print
- **Scribus** frames (manual WYSIWYG placement)
- **SVG** (standalone graphics) → embedded into either Typst or Scribus

Markdown is the durable authoring layer; Typst and Scribus are the two layout engines, split by whether the layout is *rule-driven* (Typst) or *placement-driven* (Scribus); SVG is the graphics layer that either can consume.

## Structured data

Tables, citations, hierarchized records, and indexes aren't competitors to the four formats above — they're a layer that feeds into them. None of the four represent raw structured data on their own terms; they consume or display it.

| Format | Spec / reference | Processor | Territory | Weak at | If the tool disappears |
|---|---|---|---|---|---|
| **CSV** | RFC 4180 (informational, not prescriptive — real-world CSV is a family of dialects) | any parser or spreadsheet | flat tabular records | hierarchy, typed fields | already at maximum legibility — nothing to degrade to |
| **TOML** | formal, versioned spec | any conformant parser | shallow, config-shaped hierarchized records | deep/arbitrary nesting | plain text, unambiguous, safely hand-editable |
| **YAML** | YAML 1.2 spec | any conformant parser; native to Typst via Hayagriva | deep hierarchized records; citations | implicit typing ambiguity ("Norway problem") | plain text, but re-editing needs care around ambiguity |
| **BibTeX / Hayagriva** | BibTeX's de facto grammar / Typst's Hayagriva spec | Typst natively, or biber/bibtex for LaTeX-legacy pipelines | citations | verbose (BibTeX) or young (Hayagriva) | text-based either way, always parseable |

**Indexes fall off the grid.** A page index is *derived* by whichever layout engine (Typst or Scribus) computes final positions — it's an output of the typesetting step, not an independent source format to pick.

**Practical routing:**
- Flat records you'll bulk-edit in a spreadsheet → CSV, even for a lightweight tree (a `parent_id` column keeps it flat and spreadsheet-editable, trading elegance for bulk-editability).
- A one-off, genuinely nested structure a human authors directly → YAML if it needs to feed Typst's bibliography anyway (one less format to hold in your head); TOML if it's closer to config and correctness matters more than depth.
- Citations → Hayagriva/YAML by default in a Typst pipeline; BibTeX only if the same source must also serve a LaTeX-legacy path.

**Concrete case — genealogical records.** This is the real-world instance of the hierarchized-record trade-off above, playing out between two actual standards: **GEDCOM** is the broad-interoperability choice — text-based (its own line/level tag syntax rather than XML, but text-based regardless), a documented spec stewarded by FamilySearch, and readable/writable by nearly every genealogy tool in existence, at the cost of historic ambiguity across vendor dialects (largely tightened by GEDCOM 7). **Gramps XML** is the upgrade path when precision outweighs breadth: a properly documented XML schema that preserves the fuller research model — sources, citations, notes, media references — losslessly, at the cost of a narrower, closer-to-single-implementation profile, structurally the same trade-off as Typst against a wider LaTeX ecosystem, or Hayagriva against BibTeX.

**Neither CSV nor GEDCOM are as narrow as their usual context suggests, which matters for keeping this list short:**

- CSV's territory isn't "generic tabular data," it's *any* vertical whose specialist tools already round-trip through it — geo/mapping (point data: GPS tracks, sensor readings, geocoded addresses all interchange as lat/long columns), biotech lab instrument exports, and survey/statistical data all treat CSV as their common denominator for flat records. Real geometry — polygons, lines, multi-part features — needs its own format, and it's worth naming explicitly: **GeoJSON**, not the more entrenched Shapefile. GeoJSON is plain JSON text with a proper published standard (RFC 7946) and near-universal GIS/web-mapping support, and it degrades exactly the way this document rewards — readable and salvageable by eye. Shapefile is more entrenched in professional GIS practice and its technical spec is public too, but it fails the same two rules InDesign failed: the geometry itself (`.shp`) is raw binary, not text, and the format is fragile by design — split across three-plus sidecar files (`.shp`, `.dbf`, `.shx`, `.prj`), where losing just the `.prj` means the projection is gone with no way to recover it from what's left. Wide adoption doesn't offset either weakness here.
- GEDCOM's territory isn't strictly human genealogy either. Animal pedigree software genuinely imports/exports it (Pedigree Viewer, used in livestock breeding programs, is a real example) — that one's a natural fit since the underlying shape is identical. Enterprise org charts and abstract relation diagrams fit less naturally: GEDCOM's schema bakes in genealogical semantics (`INDI`, `FAM`, birth/death events), so reusing it there means overloading fields that don't mean what they say. **GraphML** is the better-fitting alternative — a genuinely generic XML graph format (nodes, edges, arbitrary attributes on either), with a published schema and several independent implementations (yEd, Gephi, NetworkX, igraph), and none of GEDCOM's baked-in domain assumptions. Most org charts don't even need it, though — a strict single-parent tree is already covered by the CSV adjacency-list pattern above (`id, parent_id`). GraphML earns its place once relationships stop being a clean tree: multiple relationship types (reporting line vs. dotted line vs. project assignment), attributes on the edges themselves, or genuine multi-parent structure. And if the deliverable is a *rendered* diagram rather than interchange data, Graphviz's **DOT** is the closer fit — plain text, a single compiled binary, laying out and rendering the graph directly instead of just describing it.

## Revised pipeline

- Structured data feeds Markdown:
- **CSV** (flat records)
- **YAML / TOML** (hierarchized records)
- **Hayagriva / BibTeX** (citations)
- **Markdown** (prose) →
- **Typst** (layout/typeset) → PDF/print → index (generated)
- **Scribus** (WYSIWYG)
- **SVG** (standalone graphics) → embedded into either Typst or Scribus

## Finalists — and what was ruled out

This was never a shortlist of "formats that seem fine" in the abstract — every territory had real, named alternatives that lost specifically on the four rules at the top of this document, not on capability. Naming them is what gives the selection empirical weight instead of just preference.

**Page layout / WYSIWYG → Scribus, not InDesign, Affinity Publisher, or QuarkXPress.**

- InDesign is, by capability, clearly the better tool. But `.indd` is a single-vendor proprietary binary, and Adobe's own workaround proves the underlying point: IDML, InDesign's XML export path, exists because Adobe doesn't fully trust `.indd` to stay openable long-term — and even that escape hatch is weaker than it looks, since its publicly maintained specification hasn't been updated since 2012, and round-tripping through it is lossy. On top of the format risk sits an account risk with nothing to do with price: InDesign is walled-garden software, and a suspended account can mean losing access to files you already own.
- QuarkXPress has the same profile historically, arguably worse — it was the dominant DTP format before InDesign existed, and old `.qxp` files from that era are a well-known category of orphaned files today.
- Affinity Publisher is the most interesting case, because it's a live experiment in the price-vs-openness question. Until 2025 it was a one-time purchase — closer to real ownership, which should in principle reduce vendor risk. Then Canva, which acquired Serif in 2024, relaunched the whole suite in October 2025 as a single free application. That looks like a win, but use of the app is now tied to a Canva account, and Canva's terms allow it to suspend or limit that access at any time. The price dropped to zero and the ownership position got *worse* at the same moment — clean evidence that price and future-proofing move independently, in either direction.
- The nearest real standards-body alternative is OpenDocument Graphics (`.odg`) — ISO/IEC 26300, multiple independent implementations (LibreOffice, Calligra) — but it lacks Scribus's prepress feature set (real CMYK, bleed, preflight), so it loses on capability rather than on format risk.

Scribus stays the finalist for the reason a return to an old document keeps proving in practice: it's the one that stays reopenable. That's rules 1, 2, and 4 doing their job, even while it visibly loses on rule 3 (single-binary minimalism) and on day-to-day usability to every tool it's being chosen over.

## On open source vs. proprietary

Worth being precise here, since price was never one of the four rules. What actually matters is whether continued access depends on a vendor's business model staying alive, or only on a published spec and at least one implementation existing. Open source correlates strongly with that but isn't identical to it — a single-implementation open-source project (Scribus itself, or Typst) still disappears if nobody maintains it. The difference is what's left afterward: a closed binary format becomes reverse-engineering archaeology, while an abandoned open-source codebase and its file-format documentation stay fully available to fork or study. That's the actual mechanism behind price "weighing in favor" of open source without being the deciding factor on its own — paying buys support and recourse *now*; it doesn't buy archival durability *later*, which is a different currency, and the one this whole document is trying to price in.

## Future-proofing risk, ranked

Scoped to the core pipeline formats actually chosen above — not the rejected alternatives (InDesign, Shapefile, QuarkXPress) or the domain-specific extensions (GeoJSON, GraphML, DOT), whose risk profiles are already covered inline where they're introduced.

1. **Markdown** — lowest risk. Trivial spec, dozens of parsers, degrades to something already legible.
2. **CSV** — lowest risk, same reasoning, despite the thinner spec — ubiquity of interpreters more than compensates.
3. **TOML** — low risk. Tight spec, unambiguous, plain text.
4. **SVG** — low risk. Mature W3C spec, many independent renderers; hand-editing is impractical but rarely necessary since the XML is at least inspectable.
5. **YAML** — low-to-moderate risk. Ubiquitous parsers, but the implicit-typing ambiguity is a real footgun on re-edit, not just a theoretical one.
6. **Typst** — moderate risk, mitigated. Younger and single-implementation today, but the spec is published and the source syntax is closer to prose than to a macro language — an eventual reimplementation (or a fork, given it's open source) is plausible in a way that reviving an abandoned proprietary format wouldn't be.
7. **Hayagriva** — moderate risk. Same single-implementation profile as Typst, since it's Typst's own bibliography format; BibTeX is the fallback if that specific risk matters more than the ergonomics.
8. **Scribus** — moderate-to-higher risk *for editing*, low risk *for archival*. The `.sla` XML will always be parseable, but without the app itself, meaningfully re-editing a placement-driven layout by hand is much harder than re-editing a Typst or Markdown source file.

## Scope boundary: raster image storage integrity

Deliberately excluded: how well raster formats (JPEG, TIFF, PNG) survive disk failure and bit-rot. That's a different risk axis from everything above — it's a storage-integrity problem, not a tooling/spec-obsolescence one. A format can have a perfect, permanently-implementable spec and still be destroyed by failing media; conversely, format choice affects *how gracefully* a partially corrupted file degrades, which is a real and separate question worth its own treatment rather than a footnote here.

Any attempt to invite them to my nerdy world is outright ignored, ...

2026-09-06T06:46:22Z

In reply to nevent1q…usy4
_________________________

Any attempt to invite them to my nerdy world is outright ignored, unless I can prove the actual profit

Good moment for retailers, just stock and watch the market grow ...

2026-09-06T06:21:29Z

In reply to nevent1q…cxwj
_________________________

Good moment for retailers, just stock and watch the market grow their margin

Nice article to highlight in Boris ...

2026-08-22T10:36:31Z

Nice article to highlight in Boris https://reason.com/2024/08/13/can-nostr-make-twitters-dreams-come-true. But should check some wording (NIP is short for Nostr Implementation Possibility)

Love the feeling of multi- protocol posts reading in Flare. Just ...

2026-08-19T09:46:24Z

Love the feeling of multi- protocol posts reading in Flare. Just needs some polishing as a nostr client: image loading, zaps. Just posted a couple issues in github

Nostr is suffering something like the Linux distro effect. Every ...

2026-03-30T05:17:52Z

In reply to nevent1q…mt2w
_________________________

Nostr is suffering something like the Linux distro effect. Every nostr client attracts a niche of people (just like a distro), but we always feel like in permanent beta. Of course it's a great protocol, and yes, you feel free. The good news is X is busted. General news now run on Bluesky, and tech news go Mastodon. Nostr is for nostr stuff, and some sort of Bitcoin gossip. What has to change, I don't know. Right now, here we are, with Linux for hobby, windows for work, and three different networks for three different purposes.

I'm liking Wisp. Very balanced UI, crisp performance, clean, ...

2026-03-25T18:02:24Z

In reply to nevent1q…4z95
_________________________

I'm liking Wisp. Very balanced UI, crisp performance, clean, complete experience. No issues, except perhaps the icon is a little weird, and it might keep some folks behind the fence.

I found this interesting article *La torta o pasta genovese ...

2026-02-01T10:36:45Z

In reply to nevent1q…c0zx
_________________________

I found this interesting article *La torta o pasta genovese (pâte génoise) non è un pan di Spagna* https://www.lacucinaitaliana.it/news/in-primo-piano/pan-di-spagna-storia/

Tastes great and is very light and spongy. ...

2026-02-01T10:34:49Z

In reply to nevent1q…yt5j
_________________________

Tastes great and is very light and spongy.

The cake looks good after 30', but it started shrinking as ...

2026-02-01T09:21:20Z

In reply to nevent1q…sgyf
_________________________

The cake looks good after 30', but it started shrinking as soon as I took it out of the oven

You recipe has almost twice the eggs (genovese recipe uses 4 eggs ...

2026-02-01T09:13:42Z

In reply to nevent1q…c0zx
_________________________

You recipe has almost twice the eggs (genovese recipe uses 4 eggs for 120g of both flour and sugar), so yours should be more spongy. I couldn't wait trying it (in the oven right now).

Pa de pessic (pinch bread) is how we call it in Catalan, but for ...

2026-01-31T13:11:57Z

In reply to naddr1qq…msyy
_________________________

Pa de pessic (pinch bread) is how we call it in Catalan, but for this specific recipe with no yeast, in Spanish we call it bizcocho genovés (Genovese cake)

One of the weak points of nostr publishing is that new versions ...

2026-01-25T07:10:14Z

In reply to naddr1qq…d0n6
_________________________

One of the weak points of nostr publishing is that new versions generate duplicate posts. How do you address this in Onyx?

The Blockchain paradox - It's decentralized, but relays or ...

2026-01-08T16:04:25Z

The Blockchain paradox
- It's decentralized, but relays or nodes are unaffordable for average individuals, so it ends up being somehow concentrated.
- It's based on implicit trust by signature, but users feel free and anonymous.
- Value is transferred directly between individuals, but it remains on a common ledger.
- There's complete transparency of what is transferred, and at the same time a considerable opacity of who is in charge.
- It's a volatile value, but holders feel like it's safer than most traditional values.
- There are practically no trolls in a medium with no central censorship!

Not really. I just had the feeling that I was scrolling on ...

2026-01-07T14:33:56Z

In reply to nevent1q…rvhg
_________________________

Not really. I just had the feeling that I was scrolling on Musk's platform again. Sorry about that. Please follow on.
What I like most of nostr, more than the general subject, is the general atmosphere.

Nostr event nevent1qqsf4s6m84fu9njuusyww6ps0snvwp4d92qdgrzfv3h285rey67gwmgzyqr92937a80l8whduszh2ntu3g2kv9k227m3nma0wjdu04lzu0h76efry4k

2026-01-07T14:21:40Z

Is 21 SATs the new established courtesy zap?

Hey guys, this is nostr, not X

2026-01-07T14:15:02Z

In reply to nevent1q…q8jy
_________________________

Hey guys, this is nostr, not X

That's partly true, but I must agree with @npub1rtl…jtfs in ...

2026-01-07T10:14:10Z

In reply to nevent1q…39tj
_________________________

That's partly true, but I must agree with HODL (npub1rtl…jtfs) in the idea of pride, although not necessarily related to a political boundary. A nation is also an identity around culture, language, tradition, and whatever makes us feel a group. Some nations don't have a State, and have equally strong feelings (Catalonia, Kurdistan, Palestine, Valonia, Flanders, etc)

Good for you, although you can write the same thing replacing ...

2026-01-06T07:07:08Z

In reply to nevent1q…sr3h
_________________________

Good for you, although you can write the same thing replacing America with any other place. Sorry about that. In fact, this kind of feelings often derive to dangerous ideas.

You can't take the fraud cases as the base rule to ditch the ...

2025-12-30T08:27:04Z

In reply to naddr1qq…5ldv
_________________________

You can't take the fraud cases as the base rule to ditch the whole taxation system. Of course it's wrong to defraud, but most of the infrastructures in our civilization are built from public funds, and probably the US is not a good example on health and welfare, but there are very good examples in Europe. There's no discussion about the need of a taxation system. We just need a better distribution of these funds, and perhaps a harder punishment of fraud.
Who should contribute more or less is another issue. Taxes should let the productive live somehow better than unemployed, and the unproductive rich (inherited fortunes) should pay more than active businesses. Passive intermediaries should pay more than actual creators of value. And why not, Bitcoin investors should be treated like any other investor, so that taxing wouldn't discourage the effort, just as any other productive activity. I know this is not the common feeling in this forum, but hey, we're not living in the wild. If we expect roads to be there, and good, efficient public services, we must face how all this is funded.

True, but you can still buy standard Lego sets.

2025-12-26T08:29:47Z

In reply to nevent1q…m5nl
_________________________

True, but you can still buy standard Lego sets.

The fear of something like this happening is one of the key ...

2025-12-14T07:51:15Z

In reply to nevent1q…7the
_________________________

The fear of something like this happening is one of the key reasons why I quit using Apple products. Of course, the main reason was the short life cycle of products - you are urged to constantly upgrade your products, and sooner than later they're flagged obsolete. 20 years ago there was no viable alternative besides the Windows nightmare. But currently Linux is a whole world of peace and joy, and this is specially true for developers.

Nostr event nevent1qqsyn5qeyhqvetl7sluvgz8rg292z79yk95v5pg7kazt6dvx7hdwc3czyqr92937a80l8whduszh2ntu3g2kv9k227m3nma0wjdu04lzu0h76fmqesy

2025-12-13T06:39:46Z

Has anyone noticed some unusual lagging in nostr lately?

This is like jailing a weapon manufacturer instead of the ...

2025-12-03T05:46:42Z

In reply to naddr1qp…7nng
_________________________

This is like jailing a weapon manufacturer instead of the murderer

I'm quite close to agreeing with you. I can only imagine two ...

2025-11-23T16:56:29Z

In reply to nevent1q…g4fj
_________________________

I'm quite close to agreeing with you. I can only imagine two good reasons to change the UI:
1. Fixes - the need to add, remove or change something to fix a bug or an objectively wrong detail.
2. Evolution - noticing that all similar apps have done that change and you're phasing out.
Any other subjective reason to change puts users in a perception of randomness.

The huge sense of freedom within both the Blockchain and nostr ...

2025-11-16T08:22:01Z

The huge sense of freedom within both the Blockchain and nostr can be a bit overwhelming sometimes in the fact that this freedom is used for illegal activities, to hide obscure businesses, or any sort of criminal planning. There's been a lot of hype about the inevitable need of forking Bitcoin, and the risk this would bring to stackers. But this cannot take us back to a centralized auditing instance. No way. That would destroy the very essence and motivation of a decentralized system. Perhaps we should think of some sort of a social badge, maybe by a new NIP, with a neutral color, zero by default, which could get gradually warmer by adding negative votes, and colder with positive votes. It would be like zaps, but for reputation. I know this sort of ideas would bring me a bunch of red votes, but sorry I can't stop thinking around this purple and orange pills, I can't get rid of this mind-blowing new paradigm, and about all the actual, and potential goodness enclosed. I personally understand there's nothing illegal in decentralized communication as a system. Same with decentralized value management, it should be compatible with honest taxing, and legal business. The big thing is who we trust, an institution, a business owner, a central bank, the whole society? The bigger the decision group, is necessarily better? It is a fact that one protocol came from Satoshi (whoever it may be), and the other from fiatjaf (npub180c…h6w6). We trust them because they open sourced, and therefore we believe the code is a social heritage. But all this is beyond the code, it's a whole new mindset, a treasure we want to preserve and polish, and since it's connected with real value, it's the closest to a dream come true.

You got it right

2025-11-14T16:24:54Z

In reply to nevent1q…460z
_________________________

You got it right

We as free individuals can choose what we do, and whether the ...

2025-11-14T05:45:21Z

In reply to nevent1q…pxm0
_________________________

We as free individuals can choose what we do, and whether the reason is moral or simply logical. There's no hierarchy in that, you're not superior depending on your choice. I love my kids, but would be perfectly fine otherwise. I would simply do other stuff, and would probably take more risks. As simple as that

True. That's the main reason for using Phoenix: clean, easy, ...

2025-11-10T17:58:01Z

In reply to nevent1q…kaqm
_________________________

True. That's the main reason for using Phoenix: clean, easy, and effective. All the magic happens under the hood. Perhaps the only drawback is the slightly higher fee when compared to other wallets.

If we agree that the last resort, or perhaps the critical point, ...

2025-10-27T15:19:09Z

If we agree that the last resort, or perhaps the critical point, in decentralized communication is staying connected in an eventual failure of Internet, then we should make sure nostr works on an alternative mesh, such as the reticulum network. I've seen a couple bridging projects on GitHub, but as usual, everything feels so alpha...

Plugged

2025-10-25T07:01:09Z

In reply to nevent1q…zdfa
_________________________

Plugged

Same happened to me. That's how it works. You better release ...

2025-10-25T06:59:35Z

In reply to nevent1q…nxrp
_________________________

Same happened to me. That's how it works. You better release your article later. Let it cool for a day or two.

It's your own merit, it's all in your experience, your ...

2025-10-25T06:56:13Z

In reply to nevent1q…mh4r
_________________________

It's your own merit, it's all in your experience, your ability to emphasize, and embrace difficulty. Some call it emotional intelligence, but you can call it God, if you want.

There's very few things left to make you feel truly free. ...

2025-10-23T07:52:40Z

There's very few things left to make you feel truly free. Besides driving through the woods on a driveway, or going off-road on plane mode. One way is avoiding platforms -- i.e. using @yakihonne. The other is hodling your crypto #nostr #rawyakihonne

They call it loving oneself, but it's more about knowing ...

2025-10-19T07:07:38Z

In reply to nevent1q…3crr
_________________________

They call it loving oneself, but it's more about knowing yourself, and taking others' interactions with a critical point of view, embracing reality with a smile, and building a sense of comfort within mediocrity. They call it building a defensive barrier against others, but it's rather finding the greatness in human imperfection, which is what makes every single person unique. We can call it beauty, the perfect balance of imperfection

Not if you're refurbishing or reviving an old, unbearably ...

2025-10-16T08:16:04Z

In reply to nevent1q…ruew
_________________________

Not if you're refurbishing or reviving an old, unbearably slow windows system or a road-ended Mac, and suddenly discover it's still a usable computer. Being born in a humble environment is sometimes a privilege

Not sure if Nostr is the best decentralized multipurpose protocol ...

2025-10-16T08:02:01Z

Not sure if Nostr is the best decentralized multipurpose protocol out there, not sure if it will some day become mainstream and will serve for other content besides crypto and sovereignty, but there's a long way done and still a long way to do. Keep it up #plebs!

Interesting point of view. Scaring scenario, but surprisingly the ...

2025-10-16T04:53:55Z

Interesting point of view. Scaring scenario, but surprisingly the fact is it seems like all this is not leading to any misuse. Still not widely spread, and used for an internal reflection on crypto and sovereign procedures, altogether exciting and promising.

quoting naddr1qq…9ytt

If banks and institutions are the target for bitcoiners, then Nostr users are the operators on the ground making the mission real. This isn’t metaphor. This is structural reality. Bitcoin identified the target: centralized financial control, permissioned systems, institutional gatekeeping over human value exchange. Strategic clarity matters, but identifying a target means nothing without operational capacity. Without boots on the ground. Without operators who can execute in hostile territory.

That’s where Nostr enters the battlefield.

Operating Without Permission

Special operations forces operate behind enemy lines without asking for approval. They don’t file requests with adversarial infrastructure. They don’t rely on enemy supply chains. They operate independently, cryptographically, sovereignly.

Nostr users function identically. Every note published, every relay connected to, every interaction executed bypasses the entire legacy communication infrastructure. No corporate servers decide whether your message gets delivered. No platform committee approves your content. No centralized infrastructure exists that can be sanctioned, shut down, or seized by hostile actors.

This is distributed warfare applied to information systems. When you post on Nostr, you’re not using Twitter’s infrastructure with a Bitcoin aesthetic. You’re conducting an operation through hostile digital territory using infrastructure the enemy doesn’t control and fundamentally cannot interdict. The architectural difference matters absolutely.

Cryptographic Identity as Operational Security

Spec ops operators understand a basic truth: the mission fails if you depend on enemy logistics. Your identity cannot be tied to adversarial identification systems. Your communications cannot route through their monitoring apparatus. Your operational existence must be cryptographically sovereign, independent of their permission structures.

Nostr’s key-pair identity system embodies this doctrine at the protocol level. Your npub functions as your callsign. Your nsec serves as your credential. No phone number ties you to state surveillance infrastructure. No email verification creates dependency on corporate systems. No KYC process grants adversaries the power to decide whether you exist digitally.

This isn’t merely a privacy feature. It’s operational security as foundational architecture.

The enemy, whether that’s centralized platforms, financial censors, or state surveillance apparatuses, cannot ban what they never permissioned in the first place. They cannot deplatform what never required their platform for existence. This represents asymmetric resistance through architectural sovereignty. The terrain itself favors the insurgent.

Relays as Force Multipliers

Elite military units don’t win through massed forces. They achieve strategic objectives through multiplied effectiveness. One operator positioned correctly with proper tools and training accomplishes what conventional forces cannot achieve with overwhelming numbers.

Relays embody this force multiplication principle in network form. Each relay operates as an independent node that strengthens the overall network. Not through hierarchical command. Not through centralized coordination. Through voluntary interoperability based on open protocol standards.

An operator in Nigeria can run a relay. A freedom maximalist in Uruguay can deploy another. A cypherpunk in Japan adds a third. The network grows more resilient with each independent node, yet no single relay’s compromise threatens the entire mission. The architecture distributes risk while concentrating capability.

Contrast this with centralized platforms. One deplatforming event neutralizes everyone simultaneously. One server seizure destroys the entire operational capacity. One policy change renders your entire network obsolete. Centralized systems create single points of catastrophic failure by design.

Nostr’s relay architecture eliminates this attack surface entirely. It’s not just better. It’s categorically different. It’s the difference between a conventional army that collapses when you kill the general versus a distributed insurgency where eliminating any single node strengthens the remainder’s resolve.

Zaps: Value Transfer as Tactical Support

Bitcoin proved that value transfer doesn’t require banking infrastructure. Lightning made it tactically deployable with speed and efficiency. But Nostr weaponized it at the social layer.

Zaps aren’t tips in the conventional sense. They’re kinetic financial operations. Value transfer that occurs outside every legacy financial rail, every payment processor, every institutional permission structure. When you zap someone on Nostr, you’re conducting peer-to-peer value transfer through cryptographic channels that no institution intermediates, monitors, or controls.

This represents financial fire support for content, for ideas, for resistance operations themselves. The journalist posting regime-critical content from authoritarian territory doesn’t hope a payment processor approves their funding request. They receive sats directly, instantly, globally, uncensorably. The mission stays funded even when every institution opposes it.

The circular economy implications compound exponentially. Every zap represents Bitcoin adoption in action. Not theoretical. Not advocated. Actual peer-to-peer value transfer using Bitcoin and Lightning. Nostr doesn’t just discuss Bitcoin’s value proposition. It operationalizes Bitcoin at the social coordination layer.

User Sovereignty as Operational Doctrine

Special operations succeed through operator initiative and decentralized decision-making. Not committee consensus. Not bureaucratic approval chains. Individual warfighters making battlefield decisions faster than conventional command structures can respond.

Every Nostr user operates with this same autonomy. You choose which relays to connect to. You curate your own follows and mutes. You control your cryptographic identity absolutely. You deploy whichever client serves your mission parameters. The protocol doesn’t decide for you. The network doesn’t vote on your options. You execute based on operational requirements you define.

This creates an anti-fragile resistance network. Banning users from centralized platforms creates martyrs and refugees, potentially strengthening opposition narratives but ultimately removing those voices from the platform. Banning Nostr users is conceptually meaningless because “banning” isn’t coherent when users control their own keys and choose their own infrastructure.

If one relay refuses your content, you publish to others. If one client implements unwanted features, you fork it or switch. If adversaries attempt to track your identity, your cryptographic keys protect you better than any corporate privacy policy ever could. The operation continues regardless of institutional approval or disapproval. That’s the point. That’s why it works.

The Compounding Strategic Victory

Bitcoin’s strategic objective is making institutional control of money obsolete through superior parallel infrastructure. The victory condition isn’t destroying banks through force. It’s making them irrelevant through better alternatives that people voluntarily adopt.

Nostr pursues an identical strategy for communication and social coordination. The victory condition is making platform-based social networks obsolete through superior parallel infrastructure. Not through regulation. Not through protest. Through building something so much better that the old system becomes obviously inferior.

But the force multiplication between these protocols creates compounding effects. Nostr accelerates Bitcoin adoption by making Bitcoin transactional at the social layer. Every zap is circular economy activity. Every Nostr user potentially becomes a Lightning node in social formation, normalizing Bitcoin usage for everyday interaction.

The protocol doesn’t just facilitate communication about Bitcoin. It operates Bitcoin as fundamental infrastructure for human coordination. Money and communication integrate at the protocol level, creating a coordination technology stack that legacy systems cannot match.

Why “Operators” Isn’t Hyperbole

These aren’t passive consumers hoping someone builds freedom for them. They’re active participants building the parallel infrastructure that makes enemy systems irrelevant through superior functionality.

They accept operational risk. Running relays. Managing cryptographic keys. Operating outside institutional protections and conveniences. Using experimental software that occasionally breaks. Teaching others. Writing code. Contributing documentation.

They understand mission priority: sovereignty first, convenience second. Operators don’t complain that communications equipment is heavy or that night vision goggles are uncomfortable. Nostr users don’t complain that adoption is slow or that UX needs improvement. They recognize these as temporary tactical constraints while building toward strategic victory.

Most critically, they’re building the infrastructure that makes Bitcoin’s victory inevitable at civilization scale. Money means nothing if you can’t coordinate around it, communicate about it, or socially transact with it. Nostr provides the communication and coordination layer that makes Bitcoin’s financial sovereignty operationally deployable for human civilization.

The Mission Continues

Banks and institutions aren’t just targets for philosophical critique. They represent enemy infrastructure in a war for human sovereignty. The regime of permissioned existence. Of gatekept communication. Of surveilled transactions. Of controlled identity.

Bitcoin proved you could route around them financially. Nostr proves you can route around them informationally. Together they form a complete operational doctrine: sovereign money, sovereign communication, sovereign identity. The full stack required for free human coordination at global scale.

Every user running this stack isn’t cosplaying resistance or posting revolutionary aesthetics from their iPhone. They’re conducting actual resistance operations. Building real infrastructure. Operating outside permission structures. Demonstrating through action that better systems exist.

That’s not metaphor. That’s operational reality unfolding in real time.

The target is identified. The operators are deployed. The infrastructure is live and growing.

The mission continues.

If you like the Linux command line, you probably picked your file ...

2025-10-12T14:51:45Z

If you like the Linux command line, you probably picked your file manager. If not, here's some clues.

quoting naddr1qq…360v

The console file manager battle

After the text editor battle, I needed to choose the right console file manager. When comparing console file managers, there's enough options for everyone -- dual pane apps like midnight commander, vifm; single pane, like lf, nnn; miller columns like ranger... Some of them can work in more than one mode, like ranger in dual pane, vifm in list mode. On the other hand there's the key binding headache. If vim-like keybindings is a must-have, then the choice narrows down to just a few. In my case, the finalist battle has been between two giant competitors: ranger and vifm. Both have some unique features and some lacking tools, but both deserve a place in the final.

Where both are equivalent or identical

Navigation follows the typical hjkl vim-like bindings, including yy, pp, dd...

Browsing through sibling directories is similar in both. Use [ and ] in ranger. Use [r and ]r in vifm.

Both can use the double-pane configuration, which is default in vifm. In ranger you can activate it by typing tilde (~), and then creating a new tab (gn).

Both can use the Miller column view, which is default in ranger. In vifm you can activate it by typing :set millerview.

Out of the box, you have a minimalistic list of filenames and sizes (except with folders, where ranger shows file count). To see extra columns with information like modification time, filetype, etc, you can use shift-M in ranger to set the line-mode. In vifm you need to type :set viewcolumns=-{field1},{field2}...for each pane (example :set viewcolumns=-{name},{ext},{mtime}).

Tagging files is done with t, so you can execute commands on the tagged set of files (marked with *).

Bulk renaming is done by typing a shell command. In ranger it's :bulkrename %s, while in vifm it's :rename. You then get the file list in the editor.

Renaming a single file is a bit more straighforward in ranger. You can either have the current name with the cursor ready just before the extension (use a), at the very end (use A) or in an empty field, attempting to write a whole new name (use cw for change word, like in vim). Vifm offers the first option by typing cW or the second option by typing cw.

Changing sort order is also quite different, being a little more straightforward in ranger. You use the o (order) command with different suffixes (n for natural, r for reverse, a for atime, c for ctime, m for mtime, t for type, s for size, and any of these will be reversed by using capital). In vifm you type :sor[t] and choose the criteria from the pop-up menu.

Different approaches for similar features

Some features work differently in each application. For instance, space bar in ranger marks successive files to be processed. In vifm space is just like tab, used to focus on the opposite pane.

a is used to append text to the filename in ranger. In vifm, a means 'all' for several actions.

v is used to toggle marked files, which is very useful in some cases. Vifm uses v to toggle visual mode (capital V in ranger).

z is used to toggle different settings in ranger, while in vifm is used in similar ways to redraw the file list. The results are similar, but they use different bindings. To toggle showing hidden files ranger uses zh while vifm uses za. zf is used to make a permanent filter in vifm. Filtering in ranger is somehow more logical (see next section). In ranger you can use zd to list directories first, zi to toggle image previews.

Where ranger wins

The following features are unique, or somehow offer a more convenient procedure in ranger.

Filtering out directories or files is easy. Just type .f or .d. You can also apply other filters to the stack, like .l for symlinks. Filtering by text is like a fast search, and lets you find any name containing a specific character. Type f and the character. Then tab navigates through all the occurrences.

Yanking files from different directories is possible in ranger by adding new files with the ya binding. You can also add files to the delete buffer (da). When you're done or want to start over, remember to clear the buffer using uy or ud.

Symlink management is quite logical and versatile in ranger. You can paste a soft symlink of a yanked file by typing pl (absolute) or pL (relative). If you type phl you get a hard link instead. You can even make a whole subdirectory with hard links to all files by typing pht. To paste a relative link in vifm you type rl, and al for absolute. This syntax doesn't follow the top-down logic, which is usual in ranger.

The :flat command lets you view the current directory and all the children items in the same list. For instance :flat 1 shows the first two levels together as a list.

Despite being written in python, and thus being technically slower, ranger behaves in a very fluent manner. Vifm is generally faster, but some processes take longer, like changing to millerview.

Where vifm wins

vifm is generally faster than ranger, mainly because it's written in C.

Cut and paste is done differently. Instead of dd and pp, you must use yy and capital P. This has the logic of moving the copied files directly to the destinations, thus avoiding the need of a buffer in the middle. This means dd is not cutting, but trashing in vifm.

File and folder sizes are recalculated using ga, or gA if you need to force recalculate. Ranger doesn't offer this feature.

Changing names to uppercase (gUU) or lowercase (guu) is only available in vifm (also in lf). This is not available as a ranger function, but you can always achieve the same result by bulk-renaming in vim, or your editor of choice.

List view (lsview) can be useful for big amounts of files. This is an exclusive mode of vifm. You activate it with :set lsview.

So which of the two is better overall?

There's a lot of extra functionality in both applications, which can't be covered thoroughly in this article. After trying both applications for some time, I should say there is a technical tie between this giant toolkits. It finally depends on personal preference whether you should use one or the other. I'm afraid you will have to decide on your own, depending on your needs and preferences. However, I bet you'll have guessed which one I picked as my daily driver.

Using both is of course a possibility, but I really recommend to stick to one for a while. Muscle memory gets a big benefit of using the same tool over and over.

I hope this article has been useful, at least to save you some hours of tinkering and testing. Good luck in your choice!

Open source, text based, simple tools, is what democracy is about ...

2025-10-12T09:06:55Z

Open source, text based, simple tools, is what democracy is about #plebs

quoting naddr1qv…trr9

Ten years ago I worked for the University, and was admittedly quite surprised about the academic world. One of the key pieces of academic research is reference management. These valuable assets are hard to manage, because formats are so changing, and sources so unlike, that the only way to prevent becoming crazy is using a robust reference management software. I was introduced to RefWorks, and then recalled my brother using EndNote. These are probably the biggest competitors in the professional Reasearch scenario, but they are expensive and probably an overkill for a freelance guy or an independent researcher. If this is your case, you might like to follow on and check the result of my own experience with these tools. back in 2014, I spent some time testing the following alternative tools:

CiteUlike.org, a very nice online database for references, capable of exporting many different formats, but with no integration for MS Word or Open Office. This is important if you’re going to use the references with the ability to eventually change formats and/or add items. Bibsonomy.org is a similar tool, broader in applications, but even less powerful in reference formatting.

Mendeley.com represents a step further in formatting, with an accurate result, and supposedly offering a Word plugin, but I couldn’t manage to install it. The browser tool to fetch references is a neat feature, and the standalone application a great piece of software, but I’m sorry, I needed the Word plugin. Besides this fact, Mendeley also uses a central server to store all your references, and if you reach the storage limit (big enough for me) then you have to start paying a monthly fee.

Scholar’s Aid and Bibus are two cute little gadgets that could do the job, but they spend a lot of resources in doing more things, while they forget to focus on robustness and practicity. The quitting reason in both cases was the inability to import and export correctly. The Word integration is quite impressive in Scolar’s Aid, but not very flexible, while Bibus didn’t integrate very well in general.

Zotero.org is very similar to Mendeley: it uses a local utility (in this case under the shape of a Firefox plugin), a Word / Open Office plugin, and a central server with a storage limit for free use. The main difference is… it works. The Word plugin is simple and functional, easy to use and very powerful, allowing you to format references as footnotes or endnotes, and allowing you to reformat lists in any desired format. Working in the cloud is good if you use different computers in different places and you want a single consistent reference database. The result of all this was I used Zotero for years, and felt very happy about it.

But I have recently found a red line for this tool. A local magazine just asked me to write an article, and I had the urge to write references in a very specific format. Custom formats in Zotero are a painful job, to the point that I couldn’t manage to do it. I tried to edit an existing format, but it didn’t work.

So here I am testing new tools again, ten years later, with the feeling of stepping back to the early years before WYSIWYG.

After some unsuccessful tinkering with native references in Word or LibreOffice, I stumbled upon JabRef, a very simple interface to BibTex files, with a straight forward concept about formats, and it seems like I found the missing piece of this puzzle

JabRef. There’s no perfect piece, and this is no exception. It will only integrate well with LibreOffice Write through a plugin, but I can use that. You can find Linux, and Windows versions. The current version has some bugs too — it will freeze with specific clicks at specific moments, but as soon as you save often enough, it does the job.

Depending on the size of your database, you can keep the core reference database on any other platform, and work on partial BibTex exports, or manage the whole thing in JabRef. Hopefully, the future will probably bring a broader integration scenario, and fix the bugs.

As a regular Linux user, I tend to prefer open, text based formats (such as BibTex), and simple tools specialized in one task, rather than big multipurpose applications. This open-source tool fits neatly in this category, and that’s why it will be my tool of choice for this assignment, and hopefully for the next following years.

The real value of Blockchain-integrated content publishing. What ...

2025-10-12T06:50:59Z

The real value of Blockchain-integrated content publishing. What is needed to turn this into a widespread standard, a real replacement of Twitter+Medium+Patreon, I don't know

quoting naddr1qq…fdhz

Not too long ago, I tried to paint a picture of what a vision for a value-enabled web could look like. Now, only a couple of months later, all this stuff is being built. On nostr, and on lightning. Orange and purple, a match made in heaven.

It goes without saying that I'm beyond delighted. What a time to be alive!

nostr

Here's the thing that nostr got right, and it's the same thing that Bitcoin got right: information is easy to spread and hard to stifle.¹ Information can be copied quickly and perfectly, which is, I believe, the underlying reason for its desire to be free.

Easy to spread, hard to stifle. That's the base reality of the nature of information. As always, the smart thing is to work with nature, not against it.² That's what's beautiful about the orange coin and the purple ostrich: both manage to work with the peculiarities of information, not against them. Both realize that information can and should be copied, as it can be perfectly read and easily spread, always. Both understand that resistance to censorship comes from writing to many places, making the cost of deletion prohibitive.

Information does not just want to be free, it longs to be free. Information expands to fill the available storage space. Information is Rumor's younger, stronger cousin; Information is fleeter of foot, has more eyes, knows more, and understands less than Rumor.

—Eric Hughes, A Cypherpunk's Manifesto

Nostr is quickly establishing itself as a base layer for information exchange, one that is identity-native and value-enabled. It is distinctly different from systems that came before it, just like Bitcoin is distinctly different from monies that came before it.

As of today, the focus of nostr is mostly on short text notes, the so-called "type 1" events more commonly known as tweets.³ However, as you should be aware by now, nostr is way more than just an alternative to twitter. It is a new paradigm. Change the note kind from 1 to 30023 and you don't have an alternative to Twitter, but a replacement for Medium, Substack, and all the other long-form platforms. I believe that special-purpose clients that focus on certain content types will emerge over time, just like we have seen the emergence of special-purpose platforms in the Web 2.0 era. This time, however, the network effects are cumulative, not separate. A new paradigm.

Let me now turn to one such special-purpose client, a nostr-based reading app.

Reading

I'm constantly surprised that, even though most people do read a lot online, very few people seem to have a reading workflow or reading tools.

Why that is is anyone's guess, but maybe the added value of such tools is not readily apparent. You can just read the stuff right there, on the ad-ridden, dead-ugly site, right? Why should you sign up for another site, use another app, or bind yourself to another closed platform?

That's a fair point, but the success of Medium and Substack shows that there is an appetite for clean reading and writing, as well as providing avenues for authors to get paid for their writing (and a willingness of readers to support said authors, just because).

The problem is, of course, that all of these platforms are platforms, which is to say, walled gardens that imprison readers and writers alike. Worse than that: they are fiat platforms, which means that permissionless value-flows are not only absent from their DNA, they are outright impossible.⁴

Nostr fixes this.

The beauty of nostr is that it is not a platform. It's a protocol, which means that you don't have to sign up for it---you can create an identity yourself. You don't have to ask for permission; you just do, without having to rely on the benevolence of whatever dictator is in charge of the platform right now.

Nostr is not a platform, and yet, powerful tools and services can be built and monetized on top of it. This is good for users, good for service providers, and good for the network(s) at large. Win-win-win.

So what am I talking about, exactly? How can nostr improve everyone's reading (and writing) experience?

Allow me to paint a (rough) picture of what I have in mind. Nostr already supports private and public bookmarks, so let's start from there.

Imagine a special-purpose client that scans all your bookmarks for long-form content.⁵ Everything that you marked to be read later is shown in an orderly fashion, which is to say searchable, sortable, filterable, and displayed without distractions. Voilà, you have yourself a reading app. That's, in essence, how Pocket, Readwise, and other reading apps work. But all these apps are walled gardens without much interoperability and without direct monetization.

Bitcoin fixes the direct monetization part.⁶ Nostr fixes the interoperability part.

Alright, we got ourselves a boring reading app. Great. Now, imagine that users are able to highlight passages. These highlights, just like bookmarks now, could be private or public. When shared publicly, something interesting emerges: an overlay on existing content, a lens on the written Web. In other words: swarm highlights.

Imagine a visual overlay of all public highlights, automatically shining a light on what the swarm of readers found most useful, insightful, funny, etc.

Further, imagine the possibility of sharing these highlights as a "type 1" event with one click, automatically tagging the highlighter(s)---as well as the author, of course---so that eventual sat-flows can be split and forwarded automatically.

Voilà, you have a system that allows for value to flow back to those who provide it, be it authors, editors, curators, or readers that willingly slog through the information jungle to share and highlight the best stuff (which is a form of curation, of course).

Zaps make nostr a defacto address book⁷ of payment information, which is to say lightning addresses, as of now. Thanks to nostr wallet connect (among other developments), sending sats ~~will soon be~~ is already as frictionless as leaving a like.

Value-for-value and participatory payment flows are something that traditional reading apps desperately lack, be it Pocket, Instapaper, Readwise, or the simple reading mode that is part of every browser.

A neat side-effect of a more structured way to share passages of text is that it enables semi-structured discussions around said passages---which could be another useful overlay inside special-purpose clients, providing context and further insights.⁸

Further, imagine the option of seamlessly switching from text-on-screen to text-to-speech, allowing the user to stream sats if desired, as Podcasting 2.0 clients already do.⁹

Imagine user-built curations of the best articles of the week, bundled neatly for your reading pleasure, incentivized by a small value split that allows the curator to participate in the flow of sats.

You get the idea.

I'm sure that the various implementation details will be hashed out, but as I see it, 90% of the stuff is already there. Maybe we'll need another NIP or two, but I don't see a reason why this can't be built---and, more importantly: I don't see a reason why it wouldn't be sustainable for everyone involved.

Most puzzle pieces are already there, and the rest of them can probably be implemented by custom event types. From the point of view of nostr, most everything is an event: bookmarks are events, highlights are events, marking something as read is an event, and sharing an excerpt or a highlight is an event. Public actions are out in the open, private actions are encrypted, the data is not in a silo, and everyone wins. Especially the users, those who are at the edge of the network and usually lose out on the value generated.

In this case, the reading case, the users are mostly "consumers" of content. What changes from the producing perspective, the perspective of the writer?

Writing

Back to the one thing that nostr got right: information is easy to spread but hard to stifle. In addition to that, digital information can be copied perfectly, which is why it shouldn't matter where stuff is published in the first place.

Allow me to repeat this point in all caps, for emphasis: IT SHOULD NOT MATTER WHERE INFORMATION IS PUBLISHED, and, maybe even more importantly, it shouldn't matter if it is published in a hundred different places at once.¹⁰

What matters is trust and accuracy, which is to say, digital signatures and reputation. To translate this to nostr speak: because every event is signed by default, as long as you trust the person behind the signature, it doesn't matter from which relay the information is fetched.

This is already true (or mostly true) on the regular web. Whether you read the internet archive version of an article or the version that is published by an online magazine, the version on the author's website, or the version read by some guy that has read more about Bitcoin than anyone else you know¹¹---it's all the same, essentially. What matters is the information itself.

Practically speaking, the source of truth in a hypernostrized world is---you guessed it---an event. An event signed by the author, which allows for the information to be wrapped in a tamper-proof manner, which in turn allows the information to spread far and wide---without it being hosted in one place.

The first clients that focus on long-form content already exist, and I expect more clients to pop up over time.¹² As mentioned before, one could easily imagine prism-like value splits seamlessly integrated into these clients, splitting zaps automatically to compensate writers, editors, proofreaders, and illustrators in a V4V fashion. Further, one could imagine various compute-intensive services built into these special-purpose clients, such as GPT Ghostwriters, or writing aids such as Grammarly and the like. All these services could be seamlessly paid for in sats, without the requirement of any sign-ups or the gathering of any user data. That's the beauty of money proper.

Plagiarism is one issue that needs to be dealt with, of course. Humans are greedy, and some humans are assholes. Neither bitcoin nor nostr fixes this. However, while plagiarism detection is not necessarily trivial, it is also not impossible, especially if most texts are published on nostr first. Nostr-based publishing tools allow for OpenTimestamp attestations thanks to NIP-03, which in turn allows for plagiarism detection based on "first seen" lookups.

That's just one way to deal with the problem, of course. In any case, I'm confident that we'll figure it out.

Value

I believe that in the open ~~attention~~ information economy we find ourselves in, value will mostly derive from effective curation, dissemination, and transmission of information, not the exclusive ownership of it.

Although it is still early days, the statistics around Podcasting 2.0 and nostr zaps clearly show that (a) people are willing to monetarily reward content they care about, and (b) the willingness to send sats increases as friction decreases.

The ingenious thing about boostagrams and zaps is that they are direct and visible, which is to say, public and interactive. They are neither regular transactions nor simple donations---they are something else entirely. An unforgable value signal, a special form of gratitude and appreciation.

Contrast that with a link to Paypal or Patreon: impersonal, slow, indirect, and friction-laden. It's the opposite of a super-charged interaction.

While today's information jungle increasingly presents itself in the form of (short) videos and (long-form) audio, I believe that we will see a renaissance of the written word, especially if we manage to move away from an economy built around attention, towards an economy built upon value and insight.

The orange future now has a purple hue, and I believe that it will be as bright as ever. We just have a lot of building to do.

Further Reading

A Vision for a Value-Enabled Web

The Freedom of Value

The Rediscovery of Money

Lightning Prisms

NIPs and Resources

Nostr Resources

value4value.info

nips.be

NIP-23: Long-form content

NIP-57: Event-specific zap markers

NIP-47: Nostr Wallet Connect

NIP-03: OpenTimestamps attestations for events

Originally published on dergigi.com

That's a Satoshi quote, of course: "Bitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, the network works like a distributed timestamp server, stamping the first transaction to spend a coin. It takes advantage of the nature of information being easy to spread but hard to stifle."

Paywalls work against this nature, which is why I consider them misguided at best and incredibly retarded at worst.

Refer to the various NIPs to discover the multitude of event kinds defined by the protocol.

Fiat doesn't work for the value-enabled web, as fiat rails can never be open and permissionless. Digital fiat is never money. It is---and always will be---credit.

In the nostr world long-form content is simply markdown as defined in NIP-23, but it could also be a link to an article or PDF, which in turn could get converted into markdown and posted as an event to a special relay.

...because Bitcoin makes V4V practical. (Paywalls are not the way.)

The Yellow Pages are dead, long live The Purple Pages!

Use a URI as the discussion base (instead of a highlight), and you got yourself a Disqus in purple feathers!

Whether the recipient is a text-to-speech service provider or a human narrator doesn't even matter too much, sats will flow just the same.

That's what torrents got right, and ipfs for that matter.

There is only one such guy, as we all know, and it's this Guy: TheGuySwann (npub1h8n…rpev)

BlogStack and Habla being two of them.

Just checking about #plebchain unwritten rules. After one ...

2025-09-30T17:07:36Z

Just checking about #plebchain unwritten rules. After one receives the courtesy zap, is he/she supposed or expected to zap back the same amount?

Oops, thanks! I keep confusing the multiple npubs. I think ...

2025-09-29T13:41:39Z

In reply to nevent1q…0d2g
_________________________

Oops, thanks! I keep confusing the multiple npubs. I think it's now okay

Done, thanks!

2025-09-29T08:00:03Z

In reply to nevent1q…9r5f
_________________________

Done, thanks!

Everything feels so beta or experimental between nostr & ...

2025-09-26T17:10:07Z

Everything feels so beta or experimental between nostr & lightning. I keep testing apps, and mostly all ended up in the trash. I just managed to complete some zaps using Amethyst and Phoenix wallet, and I feel like I found the very single tiny clear spot in this huge dark unfinished maze.

"Why didn't I just grab some BTC back in 2009? I was this ...

2025-09-25T17:13:33Z

"Why didn't I just grab some BTC back in 2009? I was this close to 10 buck worth, just for fun! Why?"
You've all had this obsessive thought sometime, haven't you? #plebchain #bitcoin