pixelmind

Thinking (almost) everything from scratch

Public Key

npub1qe23v0hfmlem4m0yq4656ly2z4npdjjhkuv7ltm5n0ra0chralksd6fmuc

NIP-05 Address

Profile Code

nprofile1qqsqv4gk8m5alua6ahjq2a2d0j9p2eskeftmwx004a6fh37hut37lmgpremhxue69uhhyetvv9ujuatn9emks6t5v4hx76tnv5hxx6rpwsq3uamnwvaz7tmjv4kxz7fwv46juamgd96x2mn0d9ek2tnrdpshgjtp0wa

Publishing to

relay.us.whitenoise.chat

relay.eu.whitenoise.chat

Author Public Key

npub1qe23v0hfmlem4m0yq4656ly2z4npdjjhkuv7ltm5n0ra0chralksd6fmuc

Show more details

Last Notes

2026-09-20 20:09:44 GMT

- reply

I just learned Ditto also accepts xaps

2026-09-20 20:01:27 GMT

- reply

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

2026-09-18 04:41:50 GMT

- reply

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

2026-09-13 20:22:36 GMT

- reply

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.

2026-09-07 10:30:39 GMT

# 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.

2026-09-06 06:46:22 GMT

- reply

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

2026-09-06 06:21:29 GMT

- reply

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

2026-08-22 10:36:31 GMT

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)

2026-08-19 09:46:24 GMT

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

2026-03-30 05:17:52 GMT

- reply

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.

2026-03-25 18:02:24 GMT

- reply

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.

2026-02-01 10:36:45 GMT

- reply

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/

2026-02-01 10:34:49 GMT

- reply

Tastes great and is very light and spongy. https://image.nostr.build/ed52454e882b193e7da5eab83d2c2e24eaed53fa0b6ed9ee4d1d352ffaa05f35.jpg

2026-02-01 09:21:20 GMT

- reply

The cake looks good after 30', but it started shrinking as soon as I took it out of the oven https://image.nostr.build/43f0ea03a1995a2b29606d52819009388a4e5e01d32ac19296371b531afb95e1.jpg

2026-02-01 09:13:42 GMT

- reply

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).

2026-01-31 13:11:57 GMT

- reply

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)

2026-01-25 07:10:14 GMT

- reply

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

2026-01-08 16:04:25 GMT

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!

2026-01-07 14:33:56 GMT

- reply

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.

2026-01-07 14:21:40 GMT

Is 21 SATs the new established courtesy zap?

2026-01-07 14:15:02 GMT

- reply

Hey guys, this is nostr, not X

2026-01-07 10:14:10 GMT

- reply

That's partly true, but I must agree with @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)

2026-01-06 07:07:08 GMT

- reply

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.

2025-12-30 08:27:04 GMT

- reply

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.

2025-12-26 08:29:47 GMT

- reply

True, but you can still buy standard Lego sets.

2025-12-14 07:51:15 GMT

- reply

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.

2025-12-13 06:39:46 GMT

Has anyone noticed some unusual lagging in nostr lately?

2025-12-03 05:46:42 GMT

- reply

This is like jailing a weapon manufacturer instead of the murderer

2025-11-23 16:56:29 GMT

- reply

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.

2025-11-16 08:22:01 GMT

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 @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.

2025-11-14 16:24:54 GMT

- reply

You got it right

2025-11-14 05:45:21 GMT

- reply

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

2025-11-10 17:58:01 GMT

- reply

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.

2025-10-27 15:19:09 GMT

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...

2025-10-25 07:01:09 GMT

- reply

Plugged

2025-10-25 06:59:35 GMT

- reply

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

2025-10-25 06:56:13 GMT

- reply

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.

2025-10-23 07:52:40 GMT

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

2025-10-19 07:07:38 GMT

- reply

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

2025-10-16 08:16:04 GMT

- reply

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

2025-10-16 08:02:01 GMT

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!

2025-10-16 04:53:55 GMT

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. #naddr1qq…9ytt

2025-10-12 14:51:45 GMT

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

2025-10-12 09:06:55 GMT

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

2025-10-12 06:50:59 GMT

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 #naddr1qq…fdhz

2025-09-30 17:07:36 GMT

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

2025-09-29 13:41:39 GMT

- reply

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

2025-09-29 08:00:03 GMT

- reply

Done, thanks!

2025-09-26 17:10:07 GMT

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.

2025-09-25 17:13:33 GMT

"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