@ 91bea5cd:1df4451c

Definição de ULID:

Timestamp 48 bits, Aleatoriedade 80 bits Sendo Timestamp 48 bits inteiro, tempo UNIX em milissegundos, Não ficará sem espaço até o ano 10889 d.C. e Aleatoriedade 80 bits, Fonte criptograficamente segura de aleatoriedade, se possível.

Gerar ULID

```sql

CREATE EXTENSION IF NOT EXISTS pgcrypto;

CREATE FUNCTION generate_ulid() RETURNS TEXT AS $$ DECLARE -- Crockford's Base32 encoding BYTEA = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'; timestamp BYTEA = E'\000\000\000\000\000\000'; output TEXT = '';

unix_time BIGINT; ulid BYTEA; BEGIN -- 6 timestamp bytes unix_time = (EXTRACT(EPOCH FROM CLOCK_TIMESTAMP()) * 1000)::BIGINT; timestamp = SET_BYTE(timestamp, 0, (unix_time >> 40)::BIT(8)::INTEGER); timestamp = SET_BYTE(timestamp, 1, (unix_time >> 32)::BIT(8)::INTEGER); timestamp = SET_BYTE(timestamp, 2, (unix_time >> 24)::BIT(8)::INTEGER); timestamp = SET_BYTE(timestamp, 3, (unix_time >> 16)::BIT(8)::INTEGER); timestamp = SET_BYTE(timestamp, 4, (unix_time >> 8)::BIT(8)::INTEGER); timestamp = SET_BYTE(timestamp, 5, unix_time::BIT(8)::INTEGER);

-- 10 entropy bytes ulid = timestamp || gen_random_bytes(10);

-- Encode the timestamp output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 0) & 224) >> 5)); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 0) & 31))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 1) & 248) >> 3)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 1) & 7) << 2) | ((GET_BYTE(ulid, 2) & 192) >> 6))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 2) & 62) >> 1)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 2) & 1) << 4) | ((GET_BYTE(ulid, 3) & 240) >> 4))); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 3) & 15) << 1) | ((GET_BYTE(ulid, 4) & 128) >> 7))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 4) & 124) >> 2)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 4) & 3) << 3) | ((GET_BYTE(ulid, 5) & 224) >> 5))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 5) & 31)));

-- Encode the entropy output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 6) & 248) >> 3)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 6) & 7) << 2) | ((GET_BYTE(ulid, 7) & 192) >> 6))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 7) & 62) >> 1)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 7) & 1) << 4) | ((GET_BYTE(ulid, 8) & 240) >> 4))); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 8) & 15) << 1) | ((GET_BYTE(ulid, 9) & 128) >> 7))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 9) & 124) >> 2)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 9) & 3) << 3) | ((GET_BYTE(ulid, 10) & 224) >> 5))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 10) & 31))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 11) & 248) >> 3)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 11) & 7) << 2) | ((GET_BYTE(ulid, 12) & 192) >> 6))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 12) & 62) >> 1)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 12) & 1) << 4) | ((GET_BYTE(ulid, 13) & 240) >> 4))); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 13) & 15) << 1) | ((GET_BYTE(ulid, 14) & 128) >> 7))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 14) & 124) >> 2)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(ulid, 14) & 3) << 3) | ((GET_BYTE(ulid, 15) & 224) >> 5))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(ulid, 15) & 31)));

RETURN output; END $$ LANGUAGE plpgsql VOLATILE; ```

ULID TO UUID

```sql CREATE OR REPLACE FUNCTION parse_ulid(ulid text) RETURNS bytea AS $$ DECLARE -- 16byte bytes bytea = E'\x00000000 00000000 00000000 00000000'; v char[]; -- Allow for O(1) lookup of index values dec integer[] = ARRAY[ 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 255, 255, 255, 255, 255, 255, 255, 10, 11, 12, 13, 14, 15, 16, 17, 1, 18, 19, 1, 20, 21, 0, 22, 23, 24, 25, 26, 255, 27, 28, 29, 30, 31, 255, 255, 255, 255, 255, 255, 10, 11, 12, 13, 14, 15, 16, 17, 1, 18, 19, 1, 20, 21, 0, 22, 23, 24, 25, 26, 255, 27, 28, 29, 30, 31 ]; BEGIN IF NOT ulid ~* '^[0-7][0-9ABCDEFGHJKMNPQRSTVWXYZ]{25}$' THEN RAISE EXCEPTION 'Invalid ULID: %', ulid; END IF;

v = regexp_split_to_array(ulid, '');

-- 6 bytes timestamp (48 bits) bytes = SET_BYTE(bytes, 0, (dec[ASCII(v[1])] << 5) | dec[ASCII(v[2])]); bytes = SET_BYTE(bytes, 1, (dec[ASCII(v[3])] << 3) | (dec[ASCII(v[4])] >> 2)); bytes = SET_BYTE(bytes, 2, (dec[ASCII(v[4])] << 6) | (dec[ASCII(v[5])] << 1) | (dec[ASCII(v[6])] >> 4)); bytes = SET_BYTE(bytes, 3, (dec[ASCII(v[6])] << 4) | (dec[ASCII(v[7])] >> 1)); bytes = SET_BYTE(bytes, 4, (dec[ASCII(v[7])] << 7) | (dec[ASCII(v[8])] << 2) | (dec[ASCII(v[9])] >> 3)); bytes = SET_BYTE(bytes, 5, (dec[ASCII(v[9])] << 5) | dec[ASCII(v[10])]);

-- 10 bytes of entropy (80 bits); bytes = SET_BYTE(bytes, 6, (dec[ASCII(v[11])] << 3) | (dec[ASCII(v[12])] >> 2)); bytes = SET_BYTE(bytes, 7, (dec[ASCII(v[12])] << 6) | (dec[ASCII(v[13])] << 1) | (dec[ASCII(v[14])] >> 4)); bytes = SET_BYTE(bytes, 8, (dec[ASCII(v[14])] << 4) | (dec[ASCII(v[15])] >> 1)); bytes = SET_BYTE(bytes, 9, (dec[ASCII(v[15])] << 7) | (dec[ASCII(v[16])] << 2) | (dec[ASCII(v[17])] >> 3)); bytes = SET_BYTE(bytes, 10, (dec[ASCII(v[17])] << 5) | dec[ASCII(v[18])]); bytes = SET_BYTE(bytes, 11, (dec[ASCII(v[19])] << 3) | (dec[ASCII(v[20])] >> 2)); bytes = SET_BYTE(bytes, 12, (dec[ASCII(v[20])] << 6) | (dec[ASCII(v[21])] << 1) | (dec[ASCII(v[22])] >> 4)); bytes = SET_BYTE(bytes, 13, (dec[ASCII(v[22])] << 4) | (dec[ASCII(v[23])] >> 1)); bytes = SET_BYTE(bytes, 14, (dec[ASCII(v[23])] << 7) | (dec[ASCII(v[24])] << 2) | (dec[ASCII(v[25])] >> 3)); bytes = SET_BYTE(bytes, 15, (dec[ASCII(v[25])] << 5) | dec[ASCII(v[26])]);

RETURN bytes; END $$ LANGUAGE plpgsql IMMUTABLE;

CREATE OR REPLACE FUNCTION ulid_to_uuid(ulid text) RETURNS uuid AS $$ BEGIN RETURN encode(parse_ulid(ulid), 'hex')::uuid; END $$ LANGUAGE plpgsql IMMUTABLE; ```

UUID to ULID

```sql CREATE OR REPLACE FUNCTION uuid_to_ulid(id uuid) RETURNS text AS $$ DECLARE encoding bytea = '0123456789ABCDEFGHJKMNPQRSTVWXYZ'; output text = ''; uuid_bytes bytea = uuid_send(id); BEGIN

-- Encode the timestamp output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 0) & 224) >> 5)); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 0) & 31))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 1) & 248) >> 3)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 1) & 7) << 2) | ((GET_BYTE(uuid_bytes, 2) & 192) >> 6))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 2) & 62) >> 1)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 2) & 1) << 4) | ((GET_BYTE(uuid_bytes, 3) & 240) >> 4))); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 3) & 15) << 1) | ((GET_BYTE(uuid_bytes, 4) & 128) >> 7))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 4) & 124) >> 2)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 4) & 3) << 3) | ((GET_BYTE(uuid_bytes, 5) & 224) >> 5))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 5) & 31)));

-- Encode the entropy output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 6) & 248) >> 3)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 6) & 7) << 2) | ((GET_BYTE(uuid_bytes, 7) & 192) >> 6))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 7) & 62) >> 1)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 7) & 1) << 4) | ((GET_BYTE(uuid_bytes, 8) & 240) >> 4))); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 8) & 15) << 1) | ((GET_BYTE(uuid_bytes, 9) & 128) >> 7))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 9) & 124) >> 2)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 9) & 3) << 3) | ((GET_BYTE(uuid_bytes, 10) & 224) >> 5))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 10) & 31))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 11) & 248) >> 3)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 11) & 7) << 2) | ((GET_BYTE(uuid_bytes, 12) & 192) >> 6))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 12) & 62) >> 1)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 12) & 1) << 4) | ((GET_BYTE(uuid_bytes, 13) & 240) >> 4))); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 13) & 15) << 1) | ((GET_BYTE(uuid_bytes, 14) & 128) >> 7))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 14) & 124) >> 2)); output = output || CHR(GET_BYTE(encoding, ((GET_BYTE(uuid_bytes, 14) & 3) << 3) | ((GET_BYTE(uuid_bytes, 15) & 224) >> 5))); output = output || CHR(GET_BYTE(encoding, (GET_BYTE(uuid_bytes, 15) & 31)));

RETURN output; END $$ LANGUAGE plpgsql IMMUTABLE; ```

Gera 11 Digitos aleatórios: YBKXG0CKTH4

```sql -- Cria a extensão pgcrypto para gerar uuid CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Cria a função para gerar ULID CREATE OR REPLACE FUNCTION gen_lrandom() RETURNS TEXT AS $$ DECLARE ts_millis BIGINT; ts_chars TEXT; random_bytes BYTEA; random_chars TEXT; base32_chars TEXT := '0123456789ABCDEFGHJKMNPQRSTVWXYZ'; i INT; BEGIN -- Pega o timestamp em milissegundos ts_millis := FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 1000)::BIGINT;

-- Converte o timestamp para base32
ts_chars := '';
FOR i IN REVERSE 0..11 LOOP
    ts_chars := ts_chars || substr(base32_chars, ((ts_millis >> (5 * i)) & 31) + 1, 1);
END LOOP;

-- Gera 10 bytes aleatórios e converte para base32
random_bytes := gen_random_bytes(10);
random_chars := '';
FOR i IN 0..9 LOOP
    random_chars := random_chars || substr(base32_chars, ((get_byte(random_bytes, i) >> 3) & 31) + 1, 1);
    IF i < 9 THEN
        random_chars := random_chars || substr(base32_chars, (((get_byte(random_bytes, i) & 7) << 2) | (get_byte(random_bytes, i + 1) >> 6)) & 31 + 1, 1);
    ELSE
        random_chars := random_chars || substr(base32_chars, ((get_byte(random_bytes, i) & 7) << 2) + 1, 1);
    END IF;
END LOOP;

-- Concatena o timestamp e os caracteres aleatórios
RETURN ts_chars || random_chars;

END; $$ LANGUAGE plpgsql; ```

Exemplo de USO

```sql -- Criação da extensão caso não exista CREATE EXTENSION IF NOT EXISTS pgcrypto; -- Criação da tabela pessoas CREATE TABLE pessoas ( ID UUID DEFAULT gen_random_uuid ( ) PRIMARY KEY, nome TEXT NOT NULL );

-- Busca Pessoa na tabela SELECT * FROM "pessoas" WHERE uuid_to_ulid ( ID ) = '252FAC9F3V8EF80SSDK8PXW02F'; ```

Fontes

• https://github.com/scoville/pgsql-ulid
• https://github.com/geckoboard/pgulid

@ 0fa80bd3:ea7325de

The land that belongs to the indigenous peoples of Russia has been seized by a gang of killers who have unleashed a war of extermination. They wipe out anyone who refuses to conform to their rules. Those who disagree and stay behind are tortured and killed in prisons and labor camps. Those who flee lose their homeland, dissolve into foreign cultures, and fade away. And those who stand up to protect their people are attacked by the misled and deceived. The deceived die for the unchecked greed of a single dictator—thousands from both sides, people who just wanted to live, raise their kids, and build a future.

Now, they are forced to make an impossible choice: abandon their homeland or die. Some perish on the battlefield, others lose themselves in exile, stripped of their identity, scattered in a world that isn’t theirs.

There’s been endless debate about how to fix this, how to clear the field of the weeds that choke out every new sprout, every attempt at change. But the real problem? We can’t play by their rules. We can’t speak their language or use their weapons. We stand for humanity, and no matter how righteous our cause, we will not multiply suffering. Victory doesn’t come from matching the enemy—it comes from staying ahead, from using tools they haven’t mastered yet. That’s how wars are won.

Our only resource is the will of the people to rewrite the order of things. Historian Timothy Snyder once said that a nation cannot exist without a city. A city is where the most active part of a nation thrives. But the cities are occupied. The streets are watched. Gatherings are impossible. They control the money. They control the mail. They control the media. And any dissent is crushed before it can take root.

So I started asking myself: How do we stop this fragmentation? How do we create a space where people can rebuild their connections when they’re ready? How do we build a self-sustaining network, where everyone contributes and benefits proportionally, while keeping their freedom to leave intact? And more importantly—how do we make it spread, even in occupied territory?

In 2009, something historic happened: the internet got its own money. Thanks to Satoshi Nakamoto, the world took a massive leap forward. Bitcoin and decentralized ledgers shattered the idea that money must be controlled by the state. Now, to move or store value, all you need is an address and a key. A tiny string of text, easy to carry, impossible to seize.

That was the year money broke free. The state lost its grip. Its biggest weapon—physical currency—became irrelevant. Money became purely digital.

The internet was already a sanctuary for information, a place where people could connect and organize. But with Bitcoin, it evolved. Now, value itself could flow freely, beyond the reach of authorities.

Think about it: when seedlings are grown in controlled environments before being planted outside, they get stronger, survive longer, and bear fruit faster. That’s how we handle crops in harsh climates—nurture them until they’re ready for the wild.

Now, picture the internet as that controlled environment for ideas. Bitcoin? It’s the fertile soil that lets them grow. A testing ground for new models of interaction, where concepts can take root before they move into the real world. If nation-states are a battlefield, locked in a brutal war for territory, the internet is boundless. It can absorb any number of ideas, any number of people, and it doesn’t run out of space.

But for this ecosystem to thrive, people need safe ways to communicate, to share ideas, to build something real—without surveillance, without censorship, without the constant fear of being erased.

This is where Nostr comes in.

Nostr—"Notes and Other Stuff Transmitted by Relays"—is more than just a messaging protocol. It’s a new kind of city. One that no dictator can seize, no corporation can own, no government can shut down.

It’s built on decentralization, encryption, and individual control. Messages don’t pass through central servers—they are relayed through independent nodes, and users choose which ones to trust. There’s no master switch to shut it all down. Every person owns their identity, their data, their connections. And no one—no state, no tech giant, no algorithm—can silence them.

In a world where cities fall and governments fail, Nostr is a city that cannot be occupied. A place for ideas, for networks, for freedom. A city that grows stronger the more people build within it.

@ 78b3c1ed:5033eea9

※スポットライトから移植した古い記事です。参考程度に。

これを参考にしてUmbrelのBitcoin Nodeをカスタムsignetノードにする。 以下メモ書きご容赦。備忘録程度に書き留めました。

メインネットとは共存できない。Bitcoinに依存する全てのアプリを削除しなければならない。よって実験機に導入すべき。

<手順>

1.Umbrel Bitcoin Nodeアプリのadvance settingでsignetを選択。

2.CLI appスクリプトでbitcoinを止める。 cd umbrel/scripts ./app stop bitcoin 3.bitcoin.conf, umbrel-bitcoin.conf以外を削除 ディレクトリの場所は ~/umbrel/app-data/bitcoin/data/bitcoin 4.umbrel-bitcoin.confをsu権限で編集。末尾にsignetchallengeを追加。 ``` [signet] bind=0.0.0.0:8333 bind=10.21.21.8:8334=onion

51,21,<公開鍵>,51,ae

signetchallenge=5121<公開鍵>51ae 5.appスクリプトでbitcoinを開始。 cd ~/umbrel/scripts ./app start bitcoin ``` 6.適当にディレクトリを作りgithubからbitcoindのソースをクローン。

7.bitcoindのバイナリをダウンロード、bitcoin-cliおよびbitcoin-utilを~/.local/binに置く。6.のソースからビルドしても良い。ビルド方法は自分で調べて。

8.bitcondにマイニング用のウォレットを作成 ``` alias bcli='docker exec -it bitcoin_bitcoind_1 bitcoin-cli -signet -rpcconnect=10.21.21.8 -rpcport=8332 -rpcuser=umbrel -rpcpassword=<パスワード>'

ウォレットを作る。

bcli createwallet "mining" false true "" false false

秘密鍵をインポート

bcli importprivkey "<秘密鍵>" RPCパスワードは以下で確認 cat ~/umbrel/.env | grep BITCOIN_RPC_PASS 9.ソースにあるbitcoin/contrib/signet/minerスクリプトを使ってマイニング cd <ダウンロードしたディレクトリ>/bitcoin/contrib/signet

難易度の算出

./miner \ --cli="bitcoin-cli -signet -rpcconnect=10.21.21.8 -rpcport=8332 -rpcuser=umbrel -rpcpassword=<パスワード>" calibrate \ --grind-cmd="bitcoin-util grind" --seconds 30 ★私の環境で30秒指定したら nbits=1d4271e7 と算出された。実際にこれで動かすと２分30になるけど...

ジェネシスブロック生成

./miner \ --cli="bitcoin-cli -signet -rpcconnect=10.21.21.8 -rpcport=8332 -rpcuser=umbrel -rpcpassword=<パスワード>" generate \ --address <ビットコインアドレス> \ --grind-cmd="bitcoin-util grind" --nbits=1d4271e7 \ --set-block-time=$(date +%s)

継続的にマイニング

./miner \ --cli="bitcoin-cli -signet -rpcconnect=10.21.21.8 -rpcport=8332 -rpcuser=umbrel -rpcpassword=<パスワード>" generate \ --address <ビットコインアドレス> \ --grind-cmd="bitcoin-util grind" --nbits=1d4271e7 \ --ongoing ``` ここまでやればカスタムsignetでビットコインノードが稼働する。

@ 9e69e420:d12360c2

Secretary of State Marco Rubio issued new guidance halting spending on most foreign aid grants for 90 days, including military assistance to Ukraine. This immediate order shocked State Department officials and mandates “stop-work orders” on nearly all existing foreign assistance awards.

While it allows exceptions for military financing to Egypt and Israel, as well as emergency food assistance, it restricts aid to key allies like Ukraine, Jordan, and Taiwan. The guidance raises potential liability risks for the government due to unfulfilled contracts.

A report will be prepared within 85 days to recommend which programs to continue or discontinue.

@ 40b9c85f:5e61b451

Introduction

Data Vending Machines (DVMs) have emerged as a crucial component of the Nostr ecosystem, offering specialized computational services to clients across the network. As defined in NIP-90, DVMs operate on an apparently simple principle: "data in, data out." They provide a marketplace for data processing where users request specific jobs (like text translation, content recommendation, or AI text generation)

While DVMs have gained significant traction, the current specification faces challenges that hinder widespread adoption and consistent implementation. This article explores some ideas on how we can apply the reflection pattern, a well established approach in RPC systems, to address these challenges and improve the DVM ecosystem's clarity, consistency, and usability.

The Current State of DVMs: Challenges and Limitations

The NIP-90 specification provides a broad framework for DVMs, but this flexibility has led to several issues:

1. Inconsistent Implementation

As noted by hzrd149 in "DVMs were a mistake" every DVM implementation tends to expect inputs in slightly different formats, even while ostensibly following the same specification. For example, a translation request DVM might expect an event ID in one particular format, while an LLM service could expect a "prompt" input that's not even specified in NIP-90.

2. Fragmented Specifications

The DVM specification reserves a range of event kinds (5000-6000), each meant for different types of computational jobs. While creating sub-specifications for each job type is being explored as a possible solution for clarity, in a decentralized and permissionless landscape like Nostr, relying solely on specification enforcement won't be effective for creating a healthy ecosystem. A more comprehensible approach is needed that works with, rather than against, the open nature of the protocol.

3. Ambiguous API Interfaces

There's no standardized way for clients to discover what parameters a specific DVM accepts, which are required versus optional, or what output format to expect. This creates uncertainty and forces developers to rely on documentation outside the protocol itself, if such documentation exists at all.

The Reflection Pattern: A Solution from RPC Systems

The reflection pattern in RPC systems offers a compelling solution to many of these challenges. At its core, reflection enables servers to provide metadata about their available services, methods, and data types at runtime, allowing clients to dynamically discover and interact with the server's API.

In established RPC frameworks like gRPC, reflection serves as a self-describing mechanism where services expose their interface definitions and requirements. In MCP reflection is used to expose the capabilities of the server, such as tools, resources, and prompts. Clients can learn about available capabilities without prior knowledge, and systems can adapt to changes without requiring rebuilds or redeployments. This standardized introspection creates a unified way to query service metadata, making tools like grpcurl possible without requiring precompiled stubs.

How Reflection Could Transform the DVM Specification

By incorporating reflection principles into the DVM specification, we could create a more coherent and predictable ecosystem. DVMs already implement some sort of reflection through the use of 'nip90params', which allow clients to discover some parameters, constraints, and features of the DVMs, such as whether they accept encryption, nutzaps, etc. However, this approach could be expanded to provide more comprehensive self-description capabilities.

1. Defined Lifecycle Phases

Similar to the Model Context Protocol (MCP), DVMs could benefit from a clear lifecycle consisting of an initialization phase and an operation phase. During initialization, the client and DVM would negotiate capabilities and exchange metadata, with the DVM providing a JSON schema containing its input requirements. nip-89 (or other) announcements can be used to bootstrap the discovery and negotiation process by providing the input schema directly. Then, during the operation phase, the client would interact with the DVM according to the negotiated schema and parameters.

2. Schema-Based Interactions

Rather than relying on rigid specifications for each job type, DVMs could self-advertise their schemas. This would allow clients to understand which parameters are required versus optional, what type validation should occur for inputs, what output formats to expect, and what payment flows are supported. By internalizing the input schema of the DVMs they wish to consume, clients gain clarity on how to interact effectively.

3. Capability Negotiation

Capability negotiation would enable DVMs to advertise their supported features, such as encryption methods, payment options, or specialized functionalities. This would allow clients to adjust their interaction approach based on the specific capabilities of each DVM they encounter.

Implementation Approach

While building DVMCP, I realized that the RPC reflection pattern used there could be beneficial for constructing DVMs in general. Since DVMs already follow an RPC style for their operation, and reflection is a natural extension of this approach, it could significantly enhance and clarify the DVM specification.

A reflection enhanced DVM protocol could work as follows: 1. Discovery: Clients discover DVMs through existing NIP-89 application handlers, input schemas could also be advertised in nip-89 announcements, making the second step unnecessary. 2. Schema Request: Clients request the DVM's input schema for the specific job type they're interested in 3. Validation: Clients validate their request against the provided schema before submission 4. Operation: The job proceeds through the standard NIP-90 flow, but with clearer expectations on both sides

Parallels with Other Protocols

This approach has proven successful in other contexts. The Model Context Protocol (MCP) implements a similar lifecycle with capability negotiation during initialization, allowing any client to communicate with any server as long as they adhere to the base protocol. MCP and DVM protocols share fundamental similarities, both aim to expose and consume computational resources through a JSON-RPC-like interface, albeit with specific differences.

gRPC's reflection service similarly allows clients to discover service definitions at runtime, enabling generic tools to work with any gRPC service without prior knowledge. In the REST API world, OpenAPI/Swagger specifications document interfaces in a way that makes them discoverable and testable.

DVMs would benefit from adopting these patterns while maintaining the decentralized, permissionless nature of Nostr.

Conclusion

I am not attempting to rewrite the DVM specification; rather, explore some ideas that could help the ecosystem improve incrementally, reducing fragmentation and making the ecosystem more comprehensible. By allowing DVMs to self describe their interfaces, we could maintain the flexibility that makes Nostr powerful while providing the structure needed for interoperability.

For developers building DVM clients or libraries, this approach would simplify consumption by providing clear expectations about inputs and outputs. For DVM operators, it would establish a standard way to communicate their service's requirements without relying on external documentation.

I am currently developing DVMCP following these patterns. Of course, DVMs and MCP servers have different details; MCP includes capabilities such as tools, resources, and prompts on the server side, as well as 'roots' and 'sampling' on the client side, creating a bidirectional way to consume capabilities. In contrast, DVMs typically function similarly to MCP tools, where you call a DVM with an input and receive an output, with each job type representing a different categorization of the work performed.

Without further ado, I hope this article has provided some insight into the potential benefits of applying the reflection pattern to the DVM specification.

@ 9e69e420:d12360c2

President Trump plans to withdraw 20,000 U.S. troops from Europe and expects European allies to contribute financially to the remaining military presence. Reported by ANSA, Trump aims to deliver this message to European leaders since taking office. A European diplomat noted, “the costs cannot be borne solely by American taxpayers.”

The Pentagon hasn't commented yet. Trump has previously sought lower troop levels in Europe and had ordered cuts during his first term. The U.S. currently maintains around 65,000 troops in Europe, with total forces reaching 100,000 since the Ukraine invasion. Trump's new approach may shift military focus to the Pacific amid growing concerns about China.

Sauce

@ b17fccdf:b7211155

The past 26 August, Tor introduced officially a proof-of-work (PoW) defense for onion services designed to prioritize verified network traffic as a deterrent against denial of service (DoS) attacks.

~ > This feature at the moment, is deactivate by default, so you need to follow these steps to activate this on a MiniBolt node:

• Make sure you have the latest version of Tor installed, at the time of writing this post, which is v0.4.8.6. Check your current version by typing

tor --version

Example of expected output:

Tor version 0.4.8.6. This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html) Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A and Glibc 2.36 as libc. Tor compiled with GCC version 12.2.0

~ > If you have v0.4.8.X, you are OK, if not, type sudo apt update && sudo apt upgrade and confirm to update.

• Basic PoW support can be checked by running this command:

tor --list-modules

Expected output:

relay: yes dirauth: yes dircache: yes pow: **yes**

~ > If you have pow: yes, you are OK

• Now go to the torrc file of your MiniBolt and add the parameter to enable PoW for each hidden service added

sudo nano /etc/tor/torrc

Example:

```

Hidden Service BTC RPC Explorer

HiddenServiceDir /var/lib/tor/hidden_service_btcrpcexplorer/ HiddenServiceVersion 3 HiddenServicePoWDefensesEnabled 1 HiddenServicePort 80 127.0.0.1:3002 ```

~ > Bitcoin Core and LND use the Tor control port to automatically create the hidden service, requiring no action from the user. We have submitted a feature request in the official GitHub repositories to explore the need for the integration of Tor's PoW defense into the automatic creation process of the hidden service. You can follow them at the following links:

• Bitcoin Core: https://github.com/lightningnetwork/lnd/issues/8002
• LND: https://github.com/bitcoin/bitcoin/issues/28499

---

More info:

• https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/
• https://gitlab.torproject.org/tpo/onion-services/onion-support/-/wikis/Documentation/PoW-FAQ

---

Enjoy it MiniBolter! 💙

@ 6be5cc06:5259daf0

Bitcoin: Um sistema de dinheiro eletrônico direto entre pessoas.

Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org

---

Resumo

O Bitcoin é uma forma de dinheiro digital que permite pagamentos diretos entre pessoas, sem a necessidade de um banco ou instituição financeira. Ele resolve um problema chamado gasto duplo, que ocorre quando alguém tenta gastar o mesmo dinheiro duas vezes. Para evitar isso, o Bitcoin usa uma rede descentralizada onde todos trabalham juntos para verificar e registrar as transações.

As transações são registradas em um livro público chamado blockchain, protegido por uma técnica chamada Prova de Trabalho. Essa técnica cria uma cadeia de registros que não pode ser alterada sem refazer todo o trabalho já feito. Essa cadeia é mantida pelos computadores que participam da rede, e a mais longa é considerada a verdadeira.

Enquanto a maior parte do poder computacional da rede for controlada por participantes honestos, o sistema continuará funcionando de forma segura. A rede é flexível, permitindo que qualquer pessoa entre ou saia a qualquer momento, sempre confiando na cadeia mais longa como prova do que aconteceu.

---

1. Introdução

Hoje, quase todos os pagamentos feitos pela internet dependem de bancos ou empresas como processadores de pagamento (cartões de crédito, por exemplo) para funcionar. Embora esse sistema seja útil, ele tem problemas importantes porque é baseado em confiança.

Primeiro, essas empresas podem reverter pagamentos, o que é útil em caso de erros, mas cria custos e incertezas. Isso faz com que pequenas transações, como pagar centavos por um serviço, se tornem inviáveis. Além disso, os comerciantes são obrigados a desconfiar dos clientes, pedindo informações extras e aceitando fraudes como algo inevitável.

Esses problemas não existem no dinheiro físico, como o papel-moeda, onde o pagamento é final e direto entre as partes. No entanto, não temos como enviar dinheiro físico pela internet sem depender de um intermediário confiável.

O que precisamos é de um sistema de pagamento eletrônico baseado em provas matemáticas, não em confiança. Esse sistema permitiria que qualquer pessoa enviasse dinheiro diretamente para outra, sem depender de bancos ou processadores de pagamento. Além disso, as transações seriam irreversíveis, protegendo vendedores contra fraudes, mas mantendo a possibilidade de soluções para disputas legítimas.

Neste documento, apresentamos o Bitcoin, que resolve o problema do gasto duplo usando uma rede descentralizada. Essa rede cria um registro público e protegido por cálculos matemáticos, que garante a ordem das transações. Enquanto a maior parte da rede for controlada por pessoas honestas, o sistema será seguro contra ataques.

---

2. Transações

Para entender como funciona o Bitcoin, é importante saber como as transações são realizadas. Imagine que você quer transferir uma "moeda digital" para outra pessoa. No sistema do Bitcoin, essa "moeda" é representada por uma sequência de registros que mostram quem é o atual dono. Para transferi-la, você adiciona um novo registro comprovando que agora ela pertence ao próximo dono. Esse registro é protegido por um tipo especial de assinatura digital.

O que é uma assinatura digital?

Uma assinatura digital é como uma senha secreta, mas muito mais segura. No Bitcoin, cada usuário tem duas chaves: uma "chave privada", que é secreta e serve para criar a assinatura, e uma "chave pública", que pode ser compartilhada com todos e é usada para verificar se a assinatura é válida. Quando você transfere uma moeda, usa sua chave privada para assinar a transação, provando que você é o dono. A próxima pessoa pode usar sua chave pública para confirmar isso.

Como funciona na prática?

Cada "moeda" no Bitcoin é, na verdade, uma cadeia de assinaturas digitais. Vamos imaginar o seguinte cenário:

1. A moeda está com o Dono 0 (você). Para transferi-la ao Dono 1, você assina digitalmente a transação com sua chave privada. Essa assinatura inclui o código da transação anterior (chamado de "hash") e a chave pública do Dono 1.
2. Quando o Dono 1 quiser transferir a moeda ao Dono 2, ele assinará a transação seguinte com sua própria chave privada, incluindo também o hash da transação anterior e a chave pública do Dono 2.
3. Esse processo continua, formando uma "cadeia" de transações. Qualquer pessoa pode verificar essa cadeia para confirmar quem é o atual dono da moeda.

Resolvendo o problema do gasto duplo

Um grande desafio com moedas digitais é o "gasto duplo", que é quando uma mesma moeda é usada em mais de uma transação. Para evitar isso, muitos sistemas antigos dependiam de uma entidade central confiável, como uma casa da moeda, que verificava todas as transações. No entanto, isso criava um ponto único de falha e centralizava o controle do dinheiro.

O Bitcoin resolve esse problema de forma inovadora: ele usa uma rede descentralizada onde todos os participantes (os "nós") têm acesso a um registro completo de todas as transações. Cada nó verifica se as transações são válidas e se a moeda não foi gasta duas vezes. Quando a maioria dos nós concorda com a validade de uma transação, ela é registrada permanentemente na blockchain.

Por que isso é importante?

Essa solução elimina a necessidade de confiar em uma única entidade para gerenciar o dinheiro, permitindo que qualquer pessoa no mundo use o Bitcoin sem precisar de permissão de terceiros. Além disso, ela garante que o sistema seja seguro e resistente a fraudes.

---

3. Servidor Timestamp

Para assegurar que as transações sejam realizadas de forma segura e transparente, o sistema Bitcoin utiliza algo chamado de "servidor de registro de tempo" (timestamp). Esse servidor funciona como um registro público que organiza as transações em uma ordem específica.

Ele faz isso agrupando várias transações em blocos e criando um código único chamado "hash". Esse hash é como uma impressão digital que representa todo o conteúdo do bloco. O hash de cada bloco é amplamente divulgado, como se fosse publicado em um jornal ou em um fórum público.

Esse processo garante que cada bloco de transações tenha um registro de quando foi criado e que ele existia naquele momento. Além disso, cada novo bloco criado contém o hash do bloco anterior, formando uma cadeia contínua de blocos conectados — conhecida como blockchain.

Com isso, se alguém tentar alterar qualquer informação em um bloco anterior, o hash desse bloco mudará e não corresponderá ao hash armazenado no bloco seguinte. Essa característica torna a cadeia muito segura, pois qualquer tentativa de fraude seria imediatamente detectada.

O sistema de timestamps é essencial para provar a ordem cronológica das transações e garantir que cada uma delas seja única e autêntica. Dessa forma, ele reforça a segurança e a confiança na rede Bitcoin.

---

4. Prova-de-Trabalho

Para implementar o registro de tempo distribuído no sistema Bitcoin, utilizamos um mecanismo chamado prova-de-trabalho. Esse sistema é semelhante ao Hashcash, desenvolvido por Adam Back, e baseia-se na criação de um código único, o "hash", por meio de um processo computacionalmente exigente.

A prova-de-trabalho envolve encontrar um valor especial que, quando processado junto com as informações do bloco, gere um hash que comece com uma quantidade específica de zeros. Esse valor especial é chamado de "nonce". Encontrar o nonce correto exige um esforço significativo do computador, porque envolve tentativas repetidas até que a condição seja satisfeita.

Esse processo é importante porque torna extremamente difícil alterar qualquer informação registrada em um bloco. Se alguém tentar mudar algo em um bloco, seria necessário refazer o trabalho de computação não apenas para aquele bloco, mas também para todos os blocos que vêm depois dele. Isso garante a segurança e a imutabilidade da blockchain.

A prova-de-trabalho também resolve o problema de decidir qual cadeia de blocos é a válida quando há múltiplas cadeias competindo. A decisão é feita pela cadeia mais longa, pois ela representa o maior esforço computacional já realizado. Isso impede que qualquer indivíduo ou grupo controle a rede, desde que a maioria do poder de processamento seja mantida por participantes honestos.

Para garantir que o sistema permaneça eficiente e equilibrado, a dificuldade da prova-de-trabalho é ajustada automaticamente ao longo do tempo. Se novos blocos estiverem sendo gerados rapidamente, a dificuldade aumenta; se estiverem sendo gerados muito lentamente, a dificuldade diminui. Esse ajuste assegura que novos blocos sejam criados aproximadamente a cada 10 minutos, mantendo o sistema estável e funcional.

---

5. Rede

A rede Bitcoin é o coração do sistema e funciona de maneira distribuída, conectando vários participantes (ou nós) para garantir o registro e a validação das transações. Os passos para operar essa rede são:

1. Transmissão de Transações: Quando alguém realiza uma nova transação, ela é enviada para todos os nós da rede. Isso é feito para garantir que todos estejam cientes da operação e possam validá-la.

2. Coleta de Transações em Blocos: Cada nó agrupa as novas transações recebidas em um "bloco". Este bloco será preparado para ser adicionado à cadeia de blocos (a blockchain).

3. Prova-de-Trabalho: Os nós competem para resolver a prova-de-trabalho do bloco, utilizando poder computacional para encontrar um hash válido. Esse processo é como resolver um quebra-cabeça matemático difícil.

4. Envio do Bloco Resolvido: Quando um nó encontra a solução para o bloco (a prova-de-trabalho), ele compartilha esse bloco com todos os outros nós na rede.

5. Validação do Bloco: Cada nó verifica o bloco recebido para garantir que todas as transações nele contidas sejam válidas e que nenhuma moeda tenha sido gasta duas vezes. Apenas blocos válidos são aceitos.

6. Construção do Próximo Bloco: Os nós que aceitaram o bloco começam a trabalhar na criação do próximo bloco, utilizando o hash do bloco aceito como base (hash anterior). Isso mantém a continuidade da cadeia.

Resolução de Conflitos e Escolha da Cadeia Mais Longa

Os nós sempre priorizam a cadeia mais longa, pois ela representa o maior esforço computacional já realizado, garantindo maior segurança. Se dois blocos diferentes forem compartilhados simultaneamente, os nós trabalharão no primeiro bloco recebido, mas guardarão o outro como uma alternativa. Caso o segundo bloco eventualmente forme uma cadeia mais longa (ou seja, tenha mais blocos subsequentes), os nós mudarão para essa nova cadeia.

Tolerância a Falhas

A rede é robusta e pode lidar com mensagens que não chegam a todos os nós. Uma transação não precisa alcançar todos os nós de imediato; basta que chegue a um número suficiente deles para ser incluída em um bloco. Da mesma forma, se um nó não receber um bloco em tempo hábil, ele pode solicitá-lo ao perceber que está faltando quando o próximo bloco é recebido.

Esse mecanismo descentralizado permite que a rede Bitcoin funcione de maneira segura, confiável e resiliente, sem depender de uma autoridade central.

---

6. Incentivo

O incentivo é um dos pilares fundamentais que sustenta o funcionamento da rede Bitcoin, garantindo que os participantes (nós) continuem operando de forma honesta e contribuindo com recursos computacionais. Ele é estruturado em duas partes principais: a recompensa por mineração e as taxas de transação.

Recompensa por Mineração

Por convenção, o primeiro registro em cada bloco é uma transação especial que cria novas moedas e as atribui ao criador do bloco. Essa recompensa incentiva os mineradores a dedicarem poder computacional para apoiar a rede. Como não há uma autoridade central para emitir moedas, essa é a maneira pela qual novas moedas entram em circulação. Esse processo pode ser comparado ao trabalho de garimpeiros, que utilizam recursos para colocar mais ouro em circulação. No caso do Bitcoin, o "recurso" consiste no tempo de CPU e na energia elétrica consumida para resolver a prova-de-trabalho.

Taxas de Transação

Além da recompensa por mineração, os mineradores também podem ser incentivados pelas taxas de transação. Se uma transação utiliza menos valor de saída do que o valor de entrada, a diferença é tratada como uma taxa, que é adicionada à recompensa do bloco contendo essa transação. Com o passar do tempo e à medida que o número de moedas em circulação atinge o limite predeterminado, essas taxas de transação se tornam a principal fonte de incentivo, substituindo gradualmente a emissão de novas moedas. Isso permite que o sistema opere sem inflação, uma vez que o número total de moedas permanece fixo.

Incentivo à Honestidade

O design do incentivo também busca garantir que os participantes da rede mantenham um comportamento honesto. Para um atacante que consiga reunir mais poder computacional do que o restante da rede, ele enfrentaria duas escolhas:

1. Usar esse poder para fraudar o sistema, como reverter transações e roubar pagamentos.
2. Seguir as regras do sistema, criando novos blocos e recebendo recompensas legítimas.

A lógica econômica favorece a segunda opção, pois um comportamento desonesto prejudicaria a confiança no sistema, diminuindo o valor de todas as moedas, incluindo aquelas que o próprio atacante possui. Jogar dentro das regras não apenas maximiza o retorno financeiro, mas também preserva a validade e a integridade do sistema.

Esse mecanismo garante que os incentivos econômicos estejam alinhados com o objetivo de manter a rede segura, descentralizada e funcional ao longo do tempo.

---

7. Recuperação do Espaço em Disco

Depois que uma moeda passa a estar protegida por muitos blocos na cadeia, as informações sobre as transações antigas que a geraram podem ser descartadas para economizar espaço em disco. Para que isso seja possível sem comprometer a segurança, as transações são organizadas em uma estrutura chamada "árvore de Merkle". Essa árvore funciona como um resumo das transações: em vez de armazenar todas elas, guarda apenas um "hash raiz", que é como uma assinatura compacta que representa todo o grupo de transações.

Os blocos antigos podem, então, ser simplificados, removendo as partes desnecessárias dessa árvore. Apenas a raiz do hash precisa ser mantida no cabeçalho do bloco, garantindo que a integridade dos dados seja preservada, mesmo que detalhes específicos sejam descartados.

Para exemplificar: imagine que você tenha vários recibos de compra. Em vez de guardar todos os recibos, você cria um documento e lista apenas o valor total de cada um. Mesmo que os recibos originais sejam descartados, ainda é possível verificar a soma com base nos valores armazenados.

Além disso, o espaço ocupado pelos blocos em si é muito pequeno. Cada bloco sem transações ocupa apenas cerca de 80 bytes. Isso significa que, mesmo com blocos sendo gerados a cada 10 minutos, o crescimento anual em espaço necessário é insignificante: apenas 4,2 MB por ano. Com a capacidade de armazenamento dos computadores crescendo a cada ano, esse espaço continuará sendo trivial, garantindo que a rede possa operar de forma eficiente sem problemas de armazenamento, mesmo a longo prazo.

---

8. Verificação de Pagamento Simplificada

É possível confirmar pagamentos sem a necessidade de operar um nó completo da rede. Para isso, o usuário precisa apenas de uma cópia dos cabeçalhos dos blocos da cadeia mais longa (ou seja, a cadeia com maior esforço de trabalho acumulado). Ele pode verificar a validade de uma transação ao consultar os nós da rede até obter a confirmação de que tem a cadeia mais longa. Para isso, utiliza-se o ramo Merkle, que conecta a transação ao bloco em que ela foi registrada.

Entretanto, o método simplificado possui limitações: ele não pode confirmar uma transação isoladamente, mas sim assegurar que ela ocupa um lugar específico na cadeia mais longa. Dessa forma, se um nó da rede aprova a transação, os blocos subsequentes reforçam essa aceitação.

A verificação simplificada é confiável enquanto a maioria dos nós da rede for honesta. Contudo, ela se torna vulnerável caso a rede seja dominada por um invasor. Nesse cenário, um atacante poderia fabricar transações fraudulentas que enganariam o usuário temporariamente até que o invasor obtivesse controle completo da rede.

Uma estratégia para mitigar esse risco é configurar alertas nos softwares de nós completos. Esses alertas identificam blocos inválidos, sugerindo ao usuário baixar o bloco completo para confirmar qualquer inconsistência. Para maior segurança, empresas que realizam pagamentos frequentes podem preferir operar seus próprios nós, reduzindo riscos e permitindo uma verificação mais direta e confiável.

---

9. Combinando e Dividindo Valor

No sistema Bitcoin, cada unidade de valor é tratada como uma "moeda" individual, mas gerenciar cada centavo como uma transação separada seria impraticável. Para resolver isso, o Bitcoin permite que valores sejam combinados ou divididos em transações, facilitando pagamentos de qualquer valor.

Entradas e Saídas

Cada transação no Bitcoin é composta por:

• Entradas: Representam os valores recebidos em transações anteriores.
• Saídas: Correspondem aos valores enviados, divididos entre os destinatários e, eventualmente, o troco para o remetente.

Normalmente, uma transação contém:

• Uma única entrada com valor suficiente para cobrir o pagamento.
• Ou várias entradas combinadas para atingir o valor necessário.

O valor total das saídas nunca excede o das entradas, e a diferença (se houver) pode ser retornada ao remetente como troco.

Exemplo Prático

Imagine que você tem duas entradas:

1. 0,03 BTC
2. 0,07 BTC

Se deseja enviar 0,08 BTC para alguém, a transação terá:

• Entrada: As duas entradas combinadas (0,03 + 0,07 BTC = 0,10 BTC).
• Saídas: Uma para o destinatário (0,08 BTC) e outra como troco para você (0,02 BTC).

Essa flexibilidade permite que o sistema funcione sem precisar manipular cada unidade mínima individualmente.

Difusão e Simplificação

A difusão de transações, onde uma depende de várias anteriores e assim por diante, não representa um problema. Não é necessário armazenar ou verificar o histórico completo de uma transação para utilizá-la, já que o registro na blockchain garante sua integridade.

---

10. Privacidade

O modelo bancário tradicional oferece um certo nível de privacidade, limitando o acesso às informações financeiras apenas às partes envolvidas e a um terceiro confiável (como bancos ou instituições financeiras). No entanto, o Bitcoin opera de forma diferente, pois todas as transações são publicamente registradas na blockchain. Apesar disso, a privacidade pode ser mantida utilizando chaves públicas anônimas, que desvinculam diretamente as transações das identidades das partes envolvidas.

Fluxo de Informação

• No modelo tradicional, as transações passam por um terceiro confiável que conhece tanto o remetente quanto o destinatário.
• No Bitcoin, as transações são anunciadas publicamente, mas sem revelar diretamente as identidades das partes. Isso é comparável a dados divulgados por bolsas de valores, onde informações como o tempo e o tamanho das negociações (a "fita") são públicas, mas as identidades das partes não.

Protegendo a Privacidade

Para aumentar a privacidade no Bitcoin, são adotadas as seguintes práticas:

1. Chaves Públicas Anônimas: Cada transação utiliza um par de chaves diferentes, dificultando a associação com um proprietário único.
2. Prevenção de Ligação: Ao usar chaves novas para cada transação, reduz-se a possibilidade de links evidentes entre múltiplas transações realizadas pelo mesmo usuário.

Riscos de Ligação

Embora a privacidade seja fortalecida, alguns riscos permanecem:

• Transações multi-entrada podem revelar que todas as entradas pertencem ao mesmo proprietário, caso sejam necessárias para somar o valor total.
• O proprietário da chave pode ser identificado indiretamente por transações anteriores que estejam conectadas.

---

11. Cálculos

Imagine que temos um sistema onde as pessoas (ou computadores) competem para adicionar informações novas (blocos) a um grande registro público (a cadeia de blocos ou blockchain). Este registro é como um livro contábil compartilhado, onde todos podem verificar o que está escrito.

Agora, vamos pensar em um cenário: um atacante quer enganar o sistema. Ele quer mudar informações já registradas para beneficiar a si mesmo, por exemplo, desfazendo um pagamento que já fez. Para isso, ele precisa criar uma versão alternativa do livro contábil (a cadeia de blocos dele) e convencer todos os outros participantes de que essa versão é a verdadeira.

Mas isso é extremamente difícil.

Como o Ataque Funciona

Quando um novo bloco é adicionado à cadeia, ele depende de cálculos complexos que levam tempo e esforço. Esses cálculos são como um grande quebra-cabeça que precisa ser resolvido.

• Os “bons jogadores” (nós honestos) estão sempre trabalhando juntos para resolver esses quebra-cabeças e adicionar novos blocos à cadeia verdadeira.
• O atacante, por outro lado, precisa resolver quebra-cabeças sozinho, tentando “alcançar” a cadeia honesta para que sua versão alternativa pareça válida.

Se a cadeia honesta já está vários blocos à frente, o atacante começa em desvantagem, e o sistema está projetado para que a dificuldade de alcançá-los aumente rapidamente.

A Corrida Entre Cadeias

Você pode imaginar isso como uma corrida. A cada bloco novo que os jogadores honestos adicionam à cadeia verdadeira, eles se distanciam mais do atacante. Para vencer, o atacante teria que resolver os quebra-cabeças mais rápido que todos os outros jogadores honestos juntos.

Suponha que:

• A rede honesta tem 80% do poder computacional (ou seja, resolve 8 de cada 10 quebra-cabeças).
• O atacante tem 20% do poder computacional (ou seja, resolve 2 de cada 10 quebra-cabeças).

Cada vez que a rede honesta adiciona um bloco, o atacante tem que "correr atrás" e resolver mais quebra-cabeças para alcançar.

Por Que o Ataque Fica Cada Vez Mais Improvável?

Vamos usar uma fórmula simples para mostrar como as chances de sucesso do atacante diminuem conforme ele precisa "alcançar" mais blocos:

P = (q/p)^z

• q é o poder computacional do atacante (20%, ou 0,2).
• p é o poder computacional da rede honesta (80%, ou 0,8).
• z é a diferença de blocos entre a cadeia honesta e a cadeia do atacante.

Se o atacante está 5 blocos atrás (z = 5):

P = (0,2 / 0,8)^5 = (0,25)^5 = 0,00098, (ou, 0,098%)

Isso significa que o atacante tem menos de 0,1% de chance de sucesso — ou seja, é muito improvável.

Se ele estiver 10 blocos atrás (z = 10):

P = (0,2 / 0,8)^10 = (0,25)^10 = 0,000000095, (ou, 0,0000095%).

Neste caso, as chances de sucesso são praticamente nulas.

Um Exemplo Simples

Se você jogar uma moeda, a chance de cair “cara” é de 50%. Mas se precisar de 10 caras seguidas, sua chance já é bem menor. Se precisar de 20 caras seguidas, é quase impossível.

No caso do Bitcoin, o atacante precisa de muito mais do que 20 caras seguidas. Ele precisa resolver quebra-cabeças extremamente difíceis e alcançar os jogadores honestos que estão sempre à frente. Isso faz com que o ataque seja inviável na prática.

Por Que Tudo Isso é Seguro?

• A probabilidade de sucesso do atacante diminui exponencialmente. Isso significa que, quanto mais tempo passa, menor é a chance de ele conseguir enganar o sistema.
• A cadeia verdadeira (honesta) está protegida pela força da rede. Cada novo bloco que os jogadores honestos adicionam à cadeia torna mais difícil para o atacante alcançar.

E Se o Atacante Tentar Continuar?

O atacante poderia continuar tentando indefinidamente, mas ele estaria gastando muito tempo e energia sem conseguir nada. Enquanto isso, os jogadores honestos estão sempre adicionando novos blocos, tornando o trabalho do atacante ainda mais inútil.

Assim, o sistema garante que a cadeia verdadeira seja extremamente segura e que ataques sejam, na prática, impossíveis de ter sucesso.

---

12. Conclusão

Propusemos um sistema de transações eletrônicas que elimina a necessidade de confiança, baseando-se em assinaturas digitais e em uma rede peer-to-peer que utiliza prova de trabalho. Isso resolve o problema do gasto duplo, criando um histórico público de transações imutável, desde que a maioria do poder computacional permaneça sob controle dos participantes honestos. A rede funciona de forma simples e descentralizada, com nós independentes que não precisam de identificação ou coordenação direta. Eles entram e saem livremente, aceitando a cadeia de prova de trabalho como registro do que ocorreu durante sua ausência. As decisões são tomadas por meio do poder de CPU, validando blocos legítimos, estendendo a cadeia e rejeitando os inválidos. Com este mecanismo de consenso, todas as regras e incentivos necessários para o funcionamento seguro e eficiente do sistema são garantidos.

---

Faça o download do whitepaper original em português: https://bitcoin.org/files/bitcoin-paper/bitcoin_pt_br.pdf

@ f9cf4e94:96abc355

Para esse exemplo iremos usar: | Nome | Imagem | Descrição | | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | Raspberry PI B+ | | Cortex-A53 (ARMv8) 64-bit a 1.4GHz e 1 GB de SDRAM LPDDR2, | | Pen drive | | 16Gb |

Recomendo que use o Ubuntu Server para essa instalação. Você pode baixar o Ubuntu para Raspberry Pi aqui. O passo a passo para a instalação do Ubuntu no Raspberry Pi está disponível aqui. Não instale um desktop (como xubuntu, lubuntu, xfce, etc.).

---

Passo 1: Atualizar o Sistema 🖥️

Primeiro, atualize seu sistema e instale o Tor:

bash apt update apt install tor

---

Passo 2: Criar o Arquivo de Serviço nrs.service 🔧

Crie o arquivo de serviço que vai gerenciar o servidor Nostr. Você pode fazer isso com o seguinte conteúdo:

```unit [Unit] Description=Nostr Relay Server Service After=network.target

[Service] Type=simple WorkingDirectory=/opt/nrs ExecStart=/opt/nrs/nrs-arm64 Restart=on-failure

[Install] WantedBy=multi-user.target ```

---

Passo 3: Baixar o Binário do Nostr 🚀

Baixe o binário mais recente do Nostr aqui no GitHub.

---

Passo 4: Criar as Pastas Necessárias 📂

Agora, crie as pastas para o aplicativo e o pendrive:

bash mkdir -p /opt/nrs /mnt/edriver

---

Passo 5: Listar os Dispositivos Conectados 🔌

Para saber qual dispositivo você vai usar, liste todos os dispositivos conectados:

bash lsblk

---

Passo 6: Formatando o Pendrive 💾

Escolha o pendrive correto (por exemplo, /dev/sda) e formate-o:

bash mkfs.vfat /dev/sda

---

Passo 7: Montar o Pendrive 💻

Monte o pendrive na pasta /mnt/edriver:

bash mount /dev/sda /mnt/edriver

---

Passo 8: Verificar UUID dos Dispositivos 📋

Para garantir que o sistema monte o pendrive automaticamente, liste os UUID dos dispositivos conectados:

bash blkid

---

Passo 9: Alterar o fstab para Montar o Pendrive Automáticamente 📝

Abra o arquivo /etc/fstab e adicione uma linha para o pendrive, com o UUID que você obteve no passo anterior. A linha deve ficar assim:

fstab UUID=9c9008f8-f852 /mnt/edriver vfat defaults 0 0

---

Passo 10: Copiar o Binário para a Pasta Correta 📥

Agora, copie o binário baixado para a pasta /opt/nrs:

bash cp nrs-arm64 /opt/nrs

---

Passo 11: Criar o Arquivo de Configuração 🛠️

Crie o arquivo de configuração com o seguinte conteúdo e salve-o em /opt/nrs/config.yaml:

yaml app_env: production info: name: Nostr Relay Server description: Nostr Relay Server pub_key: "" contact: "" url: http://localhost:3334 icon: https://external-content.duckduckgo.com/iu/?u= https://public.bnbstatic.com/image/cms/crawler/COINCU_NEWS/image-495-1024x569.png base_path: /mnt/edriver negentropy: true

---

Passo 12: Copiar o Serviço para o Diretório de Systemd ⚙️

Agora, copie o arquivo nrs.service para o diretório /etc/systemd/system/:

bash cp nrs.service /etc/systemd/system/

Recarregue os serviços e inicie o serviço nrs:

bash systemctl daemon-reload systemctl enable --now nrs.service

---

Passo 13: Configurar o Tor 🌐

Abra o arquivo de configuração do Tor /var/lib/tor/torrc e adicione a seguinte linha:

torrc HiddenServiceDir /var/lib/tor/nostr_server/ HiddenServicePort 80 127.0.0.1:3334

---

Passo 14: Habilitar e Iniciar o Tor 🧅

Agora, ative e inicie o serviço Tor:

bash systemctl enable --now tor.service

O Tor irá gerar um endereço .onion para o seu servidor Nostr. Você pode encontrá-lo no arquivo /var/lib/tor/nostr_server/hostname.

---

Observações ⚠️

• Com essa configuração, os dados serão salvos no pendrive, enquanto o binário ficará no cartão SD do Raspberry Pi.
• O endereço .onion do seu servidor Nostr será algo como: ws://y3t5t5wgwjif<exemplo>h42zy7ih6iwbyd.onion.

---

Agora, seu servidor Nostr deve estar configurado e funcionando com Tor! 🥳

Se este artigo e as informações aqui contidas forem úteis para você, convidamos a considerar uma doação ao autor como forma de reconhecimento e incentivo à produção de novos conteúdos.

@ 3f770d65:7a745b24

Here are my predictions for Nostr in 2025:

Decentralization: The outbox and inbox communication models, sometimes referred to as the Gossip model, will become the standard across the ecosystem. By the end of 2025, all major clients will support these models, providing seamless communication and enhanced decentralization. Clients that do not adopt outbox/inbox by then will be regarded as outdated or legacy systems.

Privacy Standards: Major clients such as Damus and Primal will move away from NIP-04 DMs, adopting more secure protocol possibilities like NIP-17 or NIP-104. These upgrades will ensure enhanced encryption and metadata protection. Additionally, NIP-104 MLS tools will drive the development of new clients and features, providing users with unprecedented control over the privacy of their communications.

Interoperability: Nostr's ecosystem will become even more interconnected. Platforms like the Olas image-sharing service will expand into prominent clients such as Primal, Damus, Coracle, and Snort, alongside existing integrations with Amethyst, Nostur, and Nostrudel. Similarly, audio and video tools like Nostr Nests and Zap.stream will gain seamless integration into major clients, enabling easy participation in live events across the ecosystem.

Adoption and Migration: Inspired by early pioneers like Fountain and Orange Pill App, more platforms will adopt Nostr for authentication, login, and social systems. In 2025, a significant migration from a high-profile application platform with hundreds of thousands of users will transpire, doubling Nostr’s daily activity and establishing it as a cornerstone of decentralized technologies.

@ 16d11430:61640947

At the intersection of philosophy, theology, physics, biology, and finance lies a terrifying truth: the fiat monetary system, in its current form, is not just an economic framework but a silent, relentless force actively working against humanity's survival. It isn't simply a failed financial model—it is a systemic engine of destruction, both externally and within the very core of our biological existence.

The Philosophical Void of Fiat

Philosophy has long questioned the nature of value and the meaning of human existence. From Socrates to Kant, thinkers have pondered the pursuit of truth, beauty, and virtue. But in the modern age, the fiat system has hijacked this discourse. The notion of "value" in a fiat world is no longer rooted in human potential or natural resources—it is abstracted, manipulated, and controlled by central authorities with the sole purpose of perpetuating their own power. The currency is not a reflection of society’s labor or resources; it is a representation of faith in an authority that, more often than not, breaks that faith with reckless monetary policies and hidden inflation.

The fiat system has created a kind of ontological nihilism, where the idea of true value, rooted in work, creativity, and family, is replaced with speculative gambling and short-term gains. This betrayal of human purpose at the systemic level feeds into a philosophical despair: the relentless devaluation of effort, the erosion of trust, and the abandonment of shared human values. In this nihilistic economy, purpose and meaning become increasingly difficult to find, leaving millions to question the very foundation of their existence.

Theological Implications: Fiat and the Collapse of the Sacred

Religious traditions have long linked moral integrity with the stewardship of resources and the preservation of life. Fiat currency, however, corrupts these foundational beliefs. In the theological narrative of creation, humans are given dominion over the Earth, tasked with nurturing and protecting it for future generations. But the fiat system promotes the exact opposite: it commodifies everything—land, labor, and life—treating them as mere transactions on a ledger.

This disrespect for creation is an affront to the divine. In many theologies, creation is meant to be sustained, a delicate balance that mirrors the harmony of the divine order. Fiat systems—by continuously printing money and driving inflation—treat nature and humanity as expendable resources to be exploited for short-term gains, leading to environmental degradation and societal collapse. The creation narrative, in which humans are called to be stewards, is inverted. The fiat system, through its unholy alliance with unrestrained growth and unsustainable debt, is destroying the very creation it should protect.

Furthermore, the fiat system drives idolatry of power and wealth. The central banks and corporations that control the money supply have become modern-day gods, their decrees shaping the lives of billions, while the masses are enslaved by debt and inflation. This form of worship isn't overt, but it is profound. It leads to a world where people place their faith not in God or their families, but in the abstract promises of institutions that serve their own interests.

Physics and the Infinite Growth Paradox

Physics teaches us that the universe is finite—resources, energy, and space are all limited. Yet, the fiat system operates under the delusion of infinite growth. Central banks print money without concern for natural limits, encouraging an economy that assumes unending expansion. This is not only an economic fallacy; it is a physical impossibility.

In thermodynamics, the Second Law states that entropy (disorder) increases over time in any closed system. The fiat system operates as if the Earth were an infinite resource pool, perpetually able to expand without consequence. The real world, however, does not bend to these abstract concepts of infinite growth. Resources are finite, ecosystems are fragile, and human capacity is limited. Fiat currency, by promoting unsustainable consumption and growth, accelerates the depletion of resources and the degradation of natural systems that support life itself.

Even the financial “growth” driven by fiat policies leads to unsustainable bubbles—inflated stock markets, real estate, and speculative assets that burst and leave ruin in their wake. These crashes aren’t just economic—they have profound biological consequences. The cycles of boom and bust undermine communities, erode social stability, and increase anxiety and depression, all of which affect human health at a biological level.

Biology: The Fiat System and the Destruction of Human Health

Biologically, the fiat system is a cancerous growth on human society. The constant chase for growth and the devaluation of work leads to chronic stress, which is one of the leading causes of disease in modern society. The strain of living in a system that values speculation over well-being results in a biological feedback loop: rising anxiety, poor mental health, physical diseases like cardiovascular disorders, and a shortening of lifespans.

Moreover, the focus on profit and short-term returns creates a biological disconnect between humans and the planet. The fiat system fuels industries that destroy ecosystems, increase pollution, and deplete resources at unsustainable rates. These actions are not just environmentally harmful; they directly harm human biology. The degradation of the environment—whether through toxic chemicals, pollution, or resource extraction—has profound biological effects on human health, causing respiratory diseases, cancers, and neurological disorders.

The biological cost of the fiat system is not a distant theory; it is being paid every day by millions in the form of increased health risks, diseases linked to stress, and the growing burden of mental health disorders. The constant uncertainty of an inflation-driven economy exacerbates these conditions, creating a society of individuals whose bodies and minds are under constant strain. We are witnessing a systemic biological unraveling, one in which the very act of living is increasingly fraught with pain, instability, and the looming threat of collapse.

Finance as the Final Illusion

At the core of the fiat system is a fundamental illusion—that financial growth can occur without any real connection to tangible value. The abstraction of currency, the manipulation of interest rates, and the constant creation of new money hide the underlying truth: the system is built on nothing but faith. When that faith falters, the entire system collapses.

This illusion has become so deeply embedded that it now defines the human experience. Work no longer connects to production or creation—it is reduced to a transaction on a spreadsheet, a means to acquire more fiat currency in a world where value is ephemeral and increasingly disconnected from human reality.

As we pursue ever-expanding wealth, the fundamental truths of biology—interdependence, sustainability, and balance—are ignored. The fiat system’s abstract financial models serve to disconnect us from the basic realities of life: that we are part of an interconnected world where every action has a reaction, where resources are finite, and where human health, both mental and physical, depends on the stability of our environment and our social systems.

The Ultimate Extermination

In the end, the fiat system is not just an economic issue; it is a biological, philosophical, theological, and existential threat to the very survival of humanity. It is a force that devalues human effort, encourages environmental destruction, fosters inequality, and creates pain at the core of the human biological condition. It is an economic framework that leads not to prosperity, but to extermination—not just of species, but of the very essence of human well-being.

To continue on this path is to accept the slow death of our species, one based not on natural forces, but on our own choice to worship the abstract over the real, the speculative over the tangible. The fiat system isn't just a threat; it is the ultimate self-inflicted wound, a cultural and financial cancer that, if left unchecked, will destroy humanity’s chance for survival and peace.

@ a367f9eb:0633efea

I’ll admit that I was wrong about Bitcoin. Perhaps in 2013. Definitely 2017. Probably in 2018-2019. And maybe even today.

Being wrong about Bitcoin is part of finally understanding it. It will test you, make you question everything, and in the words of BTC educator and privacy advocate Matt Odell, “Bitcoin will humble you”.

I’ve had my own stumbles on the way.

In a very public fashion in 2017, after years of using Bitcoin, trying to start a company with it, using it as my primary exchange vehicle between currencies, and generally being annoying about it at parties, I let out the bear.

In an article published in my own literary magazine Devolution Review in September 2017, I had a breaking point. The article was titled “Going Bearish on Bitcoin: Cryptocurrencies are the tulip mania of the 21st century”.

It was later republished in Huffington Post and across dozens of financial and crypto blogs at the time with another, more appropriate title: “Bitcoin Has Become About The Payday, Not Its Potential”.

As I laid out, my newfound bearishness had little to do with the technology itself or the promise of Bitcoin, and more to do with the cynical industry forming around it:

In the beginning, Bitcoin was something of a revolution to me. The digital currency represented everything from my rebellious youth.

It was a decentralized, denationalized, and digital currency operating outside the traditional banking and governmental system. It used tools of cryptography and connected buyers and sellers across national borders at minimal transaction costs.

…

The 21st-century version (of Tulip mania) has welcomed a plethora of slick consultants, hazy schemes dressed up as investor possibilities, and too much wishy-washy language for anything to really make sense to anyone who wants to use a digital currency to make purchases.

While I called out Bitcoin by name at the time, on reflection, I was really talking about the ICO craze, the wishy-washy consultants, and the altcoin ponzis.

What I was articulating — without knowing it — was the frame of NgU, or “numbers go up”. Rather than advocating for Bitcoin because of its uncensorability, proof-of-work, or immutability, the common mentality among newbies and the dollar-obsessed was that Bitcoin mattered because its price was a rocket ship.

And because Bitcoin was gaining in price, affinity tokens and projects that were imperfect forks of Bitcoin took off as well.

The price alone — rather than its qualities — were the reasons why you’d hear Uber drivers, finance bros, or your gym buddy mention Bitcoin. As someone who came to Bitcoin for philosophical reasons, that just sat wrong with me.

Maybe I had too many projects thrown in my face, or maybe I was too frustrated with the UX of Bitcoin apps and sites at the time. No matter what, I’ve since learned something.

I was at least somewhat wrong.

My own journey began in early 2011. One of my favorite radio programs, Free Talk Live, began interviewing guests and having discussions on the potential of Bitcoin. They tied it directly to a libertarian vision of the world: free markets, free people, and free banking. That was me, and I was in. Bitcoin was at about $5 back then (NgU).

I followed every article I could, talked about it with guests on my college radio show, and became a devoted redditor on r/Bitcoin. At that time, at least to my knowledge, there was no possible way to buy Bitcoin where I was living. Very weak.

I was probably wrong. And very wrong for not trying to acquire by mining or otherwise.

The next year, after moving to Florida, Bitcoin was a heavy topic with a friend of mine who shared the same vision (and still does, according to the Celsius bankruptcy documents). We talked about it with passionate leftists at Occupy Tampa in 2012, all the while trying to explain the ills of Keynesian central banking, and figuring out how to use Coinbase.

I began writing more about Bitcoin in 2013, writing a guide on “How to Avoid Bank Fees Using Bitcoin,” discussing its potential legalization in Germany, and interviewing Jeremy Hansen, one of the first political candidates in the U.S. to accept Bitcoin donations.

Even up until that point, I thought Bitcoin was an interesting protocol for sending and receiving money quickly, and converting it into fiat. The global connectedness of it, plus this cypherpunk mentality divorced from government control was both useful and attractive. I thought it was the perfect go-between.

But I was wrong.

When I gave my first public speech on Bitcoin in Vienna, Austria in December 2013, I had grown obsessed with Bitcoin’s adoption on dark net markets like Silk Road.

My theory, at the time, was the number and price were irrelevant. The tech was interesting, and a novel attempt. It was unlike anything before. But what was happening on the dark net markets, which I viewed as the true free market powered by Bitcoin, was even more interesting. I thought these markets would grow exponentially and anonymous commerce via BTC would become the norm.

While the price was irrelevant, it was all about buying and selling goods without permission or license.

Now I understand I was wrong.

Just because Bitcoin was this revolutionary technology that embraced pseudonymity did not mean that all commerce would decentralize as well. It did not mean that anonymous markets were intended to be the most powerful layer in the Bitcoin stack.

What I did not even anticipate is something articulated very well by noted Bitcoin OG Pierre Rochard: Bitcoin as a savings technology.

The ability to maintain long-term savings, practice self-discipline while stacking stats, and embrace a low-time preference was just not something on the mind of the Bitcoiners I knew at the time.

Perhaps I was reading into the hype while outwardly opposing it. Or perhaps I wasn’t humble enough to understand the true value proposition that many of us have learned years later.

In the years that followed, I bought and sold more times than I can count, and I did everything to integrate it into passion projects. I tried to set up a company using Bitcoin while at my university in Prague.

My business model depended on university students being technologically advanced enough to have a mobile wallet, own their keys, and be able to make transactions on a consistent basis. Even though I was surrounded by philosophically aligned people, those who would advance that to actually put Bitcoin into practice were sparse.

This is what led me to proclaim that “Technological Literacy is Doomed” in 2016.

And I was wrong again.

Indeed, since that time, the UX of Bitcoin-only applications, wallets, and supporting tech has vastly improved and onboarded millions more people than anyone thought possible. The entrepreneurship, coding excellence, and vision offered by Bitcoiners of all stripes have renewed a sense in me that this project is something built for us all — friends and enemies alike.

While many of us were likely distracted by flashy and pumpy altcoins over the years (me too, champs), most of us have returned to the Bitcoin stable.

Fast forward to today, there are entire ecosystems of creators, activists, and developers who are wholly reliant on the magic of Bitcoin’s protocol for their life and livelihood. The options are endless. The FUD is still present, but real proof of work stands powerfully against those forces.

In addition, there are now dozens of ways to use Bitcoin privately — still without custodians or intermediaries — that make it one of the most important assets for global humanity, especially in dictatorships.

This is all toward a positive arc of innovation, freedom, and pure independence. Did I see that coming? Absolutely not.

Of course, there are probably other shots you’ve missed on Bitcoin. Price predictions (ouch), the short-term inflation hedge, or the amount of institutional investment. While all of these may be erroneous predictions in the short term, we have to realize that Bitcoin is a long arc. It will outlive all of us on the planet, and it will continue in its present form for the next generation.

Being wrong about the evolution of Bitcoin is no fault, and is indeed part of the learning curve to finally understanding it all.

When your family or friends ask you about Bitcoin after your endless sessions explaining market dynamics, nodes, how mining works, and the genius of cryptographic signatures, try to accept that there is still so much we have to learn about this decentralized digital cash.

There are still some things you’ve gotten wrong about Bitcoin, and plenty more you’ll underestimate or get wrong in the future. That’s what makes it a beautiful journey. It’s a long road, but one that remains worth it.

@ 8cda1daa:e9e5bdd8

Bitcoin cracked the code for money.  Now it's time to rebuild everything else.

What about identity, trust, and collaboration? What about the systems that define how we live, create, and connect?

Bitcoin gave us a blueprint to separate money from the state. But the state still owns most of your digital life. It's time for something more radical.

Welcome to the Atomic Economy - not just a technology stack, but a civil engineering project for the digital age. A complete re-architecture of society, from the individual outward.

The Problem: We Live in Digital Captivity

Let's be blunt: the modern internet is hostile to human freedom.

You don't own your identity. You don't control your data. You don't decide what you see.

Big Tech and state institutions dominate your digital life with one goal: control.

• Poisoned algorithms dictate your emotions and behavior.
• Censorship hides truth and silences dissent.
• Walled gardens lock you into systems you can't escape.
• Extractive platforms monetize your attention and creativity - without your consent.

This isn't innovation. It's digital colonization.

A Vision for Sovereign Society

The Atomic Economy proposes a new design for society - one where: - Individuals own their identity, data, and value. - Trust is contextual, not imposed. - Communities are voluntary, not manufactured by feeds. - Markets are free, not fenced. - Collaboration is peer-to-peer, not platform-mediated.

It's not a political revolution. It's a technological and social reset based on first principles: self-sovereignty, mutualism, and credible exit.

So, What Is the Atomic Economy?

The Atomic Economy is a decentralized digital society where people - not platforms - coordinate identity, trust, and value.

It's built on open protocols, real software, and the ethos of Bitcoin. It's not about abstraction - it's about architecture.

Core Principles: - Self-Sovereignty: Your keys. Your data. Your rules. - Mutual Consensus: Interactions are voluntary and trust-based. - Credible Exit: Leave any system, with your data and identity intact. - Programmable Trust: Trust is explicit, contextual, and revocable. - Circular Economies: Value flows directly between individuals - no middlemen.

The Tech Stack Behind the Vision

The Atomic Economy isn't just theory. It's a layered system with real tools:

1. Payments & Settlement

• Bitcoin & Lightning: The foundation - sound, censorship-resistant money.
• Paykit: Modular payments and settlement flows.
• Atomicity: A peer-to-peer mutual credit protocol for programmable trust and IOUs.

2. Discovery & Matching

• Pubky Core: Decentralized identity and discovery using PKARR and the DHT.
• Pubky Nexus: Indexing for a user-controlled internet.
• Semantic Social Graph: Discovery through social tagging - you are the algorithm.

3. Application Layer

• Bitkit: A self-custodial Bitcoin and Lightning wallet.
• Pubky App: Tag, publish, trade, and interact - on your terms.
• Blocktank: Liquidity services for Lightning and circular economies.
• Pubky Ring: Key-based access control and identity syncing.

These tools don't just integrate - they stack. You build trust, exchange value, and form communities with no centralized gatekeepers.

The Human Impact

This isn't about software. It's about freedom.

• Empowered Individuals: Control your own narrative, value, and destiny.
• Voluntary Communities: Build trust on shared values, not enforced norms.
• Economic Freedom: Trade without permission, borders, or middlemen.
• Creative Renaissance: Innovation and art flourish in open, censorship-resistant systems.

The Atomic Economy doesn't just fix the web. It frees the web.

Why Bitcoiners Should Care

If you believe in Bitcoin, you already believe in the Atomic Economy - you just haven't seen the full map yet.

• It extends Bitcoin's principles beyond money: into identity, trust, coordination.
• It defends freedom where Bitcoin leaves off: in content, community, and commerce.
• It offers a credible exit from every centralized system you still rely on.
• It's how we win - not just economically, but culturally and socially.

This isn't "web3." This isn't another layer of grift. It's the Bitcoin future - fully realized.

Join the Atomic Revolution

• If you're a builder: fork the code, remix the ideas, expand the protocols.
• If you're a user: adopt Bitkit, use Pubky, exit the digital plantation.
• If you're an advocate: share the vision. Help people imagine a free society again.

Bitcoin promised a revolution. The Atomic Economy delivers it.

Let's reclaim society, one key at a time.

Learn more and build with us at Synonym.to.

@ 78b3c1ed:5033eea9

・ThunderHubで焼いたマカロンがlncli printmacaroonでどう見えるか確認した。

ThunderHub macaroon permissions

get invoices invoices:read create invoices invoices:write get payments offchain:read pay invoices offchain:write get chain transactions onchain:read send to chain address onchain:write create chain address address:write get wallet info info:read stop daemon info:write この結果によれば、offchain:wirteとonchain:writeの権限がなければそのマカロンを使うクライアントは勝手にBTCを送金することができない。 info:writeがなければ勝手にLNDを止めたりすることができない。

・lncli printmacaroonでデフォルトで作られるmacaroonのpermissionsを調べてみた。 admin.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "address:read", "address:write", "info:read", "info:write", "invoices:read", "invoices:write", "macaroon:generate", "macaroon:read", "macaroon:write", "message:read", "message:write", "offchain:read", "offchain:write", "onchain:read", "onchain:write", "peers:read", "peers:write", "signer:generate", "signer:read" ], "caveats": null } chainnotifier.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "onchain:read" ], "caveats": null } invoice.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "address:read", "address:write", "invoices:read", "invoices:write", "onchain:read" ], "caveats": null } invoices.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "invoices:read", "invoices:write" ], "caveats": null } readonly.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "address:read", "info:read", "invoices:read", "macaroon:read", "message:read", "offchain:read", "onchain:read", "peers:read", "signer:read" ], "caveats": null } router.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "offchain:read", "offchain:write" ], "caveats": null } signer.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "signer:generate", "signer:read" ], "caveats": null } walletkit.macaroon { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "address:read", "address:write", "onchain:read", "onchain:write" ], "caveats": null }

・lncli listpermissions コマンドですべての RPC メソッド URI と、それらを呼び出すために必要なマカロン権限を一覧表示できる。 LND v0.18.5-betaでやると1344行ほどのJSONができる。 AddInvoiceだとinvoice:writeのpermissionを持つmacaroonを使えばインボイスを作れるようだ。 "/lnrpc.Lightning/AddInvoice": { "permissions": [ { "entity": "invoices", "action": "write" } ] }, lncli listpermissionsからentityとactionを抜き出してみた。 ``` "entity": "address", "entity": "info", "entity": "invoices", "entity": "macaroon", "entity": "message", "entity": "offchain", "entity": "onchain", "entity": "peers", "entity": "signer",

"action": "generate" "action": "read" "action": "write" lncli とjqを組み合わせると例えば以下コマンドでinvoices:writeを必要とするRPCの一覧を表示できる。 invoices:writeだとAddInvoiceの他にホドルインボイス作成でも使ってるようだ lncli listpermissions | jq -r '.method_permissions | to_entries[] | select(.value.permissions[] | select(.entity == "invoices" and .action == "write")) | .key' /invoicesrpc.Invoices/AddHoldInvoice /invoicesrpc.Invoices/CancelInvoice /invoicesrpc.Invoices/HtlcModifier /invoicesrpc.Invoices/LookupInvoiceV2 /invoicesrpc.Invoices/SettleInvoice /lnrpc.Lightning/AddInvoice invoices:readだと以下となる。 /invoicesrpc.Invoices/SubscribeSingleInvoice /lnrpc.Lightning/ListInvoices /lnrpc.Lightning/LookupInvoice /lnrpc.Lightning/SubscribeInvoices LNの主だった機能のRPCはoffchainが必要ぽいので抜き出してみた。 offchain:write チャネルの開閉、ペイメントの送信までやってるみたい。 デフォルトのmacaroonでoffchain:writeを持ってるのはadminとrouterの2つだけ。openchannel,closechannelはonchain:writeのpermissionも必要なようだ。 /autopilotrpc.Autopilot/ModifyStatus /autopilotrpc.Autopilot/SetScores /lnrpc.Lightning/AbandonChannel /lnrpc.Lightning/BatchOpenChannel /lnrpc.Lightning/ChannelAcceptor /lnrpc.Lightning/CloseChannel /lnrpc.Lightning/DeleteAllPayments /lnrpc.Lightning/DeletePayment /lnrpc.Lightning/FundingStateStep /lnrpc.Lightning/OpenChannel /lnrpc.Lightning/OpenChannelSync /lnrpc.Lightning/RestoreChannelBackups /lnrpc.Lightning/SendCustomMessage /lnrpc.Lightning/SendPayment /lnrpc.Lightning/SendPaymentSync /lnrpc.Lightning/SendToRoute /lnrpc.Lightning/SendToRouteSync /lnrpc.Lightning/UpdateChannelPolicy /routerrpc.Router/HtlcInterceptor /routerrpc.Router/ResetMissionControl /routerrpc.Router/SendPayment /routerrpc.Router/SendPaymentV2 /routerrpc.Router/SendToRoute /routerrpc.Router/SendToRouteV2 /routerrpc.Router/SetMissionControlConfig /routerrpc.Router/UpdateChanStatus /routerrpc.Router/XAddLocalChanAliases /routerrpc.Router/XDeleteLocalChanAliases /routerrpc.Router/XImportMissionControl /wtclientrpc.WatchtowerClient/AddTower /wtclientrpc.WatchtowerClient/DeactivateTower /wtclientrpc.WatchtowerClient/RemoveTower /wtclientrpc.WatchtowerClient/TerminateSession "/lnrpc.Lightning/OpenChannel": { "permissions": [ { "entity": "onchain", "action": "write" }, { "entity": "offchain", "action": "write" } ] }, offchain:read readの方はチャネルやインボイスの状態を確認するためのpermissionのようだ。 /lnrpc.Lightning/ChannelBalance /lnrpc.Lightning/ClosedChannels /lnrpc.Lightning/DecodePayReq /lnrpc.Lightning/ExportAllChannelBackups /lnrpc.Lightning/ExportChannelBackup /lnrpc.Lightning/FeeReport /lnrpc.Lightning/ForwardingHistory /lnrpc.Lightning/GetDebugInfo /lnrpc.Lightning/ListAliases /lnrpc.Lightning/ListChannels /lnrpc.Lightning/ListPayments /lnrpc.Lightning/LookupHtlcResolution /lnrpc.Lightning/PendingChannels /lnrpc.Lightning/SubscribeChannelBackups /lnrpc.Lightning/SubscribeChannelEvents /lnrpc.Lightning/SubscribeCustomMessages /lnrpc.Lightning/VerifyChanBackup /routerrpc.Router/BuildRoute /routerrpc.Router/EstimateRouteFee /routerrpc.Router/GetMissionControlConfig /routerrpc.Router/QueryMissionControl /routerrpc.Router/QueryProbability /routerrpc.Router/SubscribeHtlcEvents /routerrpc.Router/TrackPayment /routerrpc.Router/TrackPaymentV2 /routerrpc.Router/TrackPayments /wtclientrpc.WatchtowerClient/GetTowerInfo /wtclientrpc.WatchtowerClient/ListTowers /wtclientrpc.WatchtowerClient/Policy /wtclientrpc.WatchtowerClient/Stats ・おまけ1 RPCメソッド名にopenを含む要素を抽出するコマンド lncli listpermissions | jq '.method_permissions | to_entries[] | select(.key | test("open"; "i"))' { "key": "/lnrpc.Lightning/BatchOpenChannel", "value": { "permissions": [ { "entity": "onchain", "action": "write" }, { "entity": "offchain", "action": "write" } ] } } { "key": "/lnrpc.Lightning/OpenChannel", "value": { "permissions": [ { "entity": "onchain", "action": "write" }, { "entity": "offchain", "action": "write" } ] } } { "key": "/lnrpc.Lightning/OpenChannelSync", "value": { "permissions": [ { "entity": "onchain", "action": "write" }, { "entity": "offchain", "action": "write" } ] } } ・おまけ２ thunderhubで作ったmacaroonはテキストで出力されコピペして使うもので、macaroonファイルになってない。 HEXをmacaroonファイルにするには以下コマンドでできる。HEXをコピペして置換する。またYOURSの箇所を自分でわかりやすい名称に置換すると良い。 echo -n "HEX" | xxd -r -p > YOURS.macaroon thunderhubで"Create Invoices, Get Invoices, Get Wallet Info, Get Payments, Pay Invoices"をチェックして作ったmacaroonのpermissionsは以下となる。 { "version": 2, "location": "lnd", "root_key_id": "0", "permissions": [ "info:read", "invoices:read", "invoices:write", "offchain:read", "offchain:write" ], "caveats": null } ``` offchain:writeはあるがonchain:writeがないのでチャネル開閉はできないはず。

@ af9c48b7:a3f7aaf4

Chef's notes

This simple, easy, no bake desert will surely be the it at you next family gathering. You can keep it a secret or share it with the crowd that this is a healthy alternative to normal pie. I think everyone will be amazed at how good it really is.

Details

• ⏲️ Prep time: 30
• 🍳 Cook time: 0
• 🍽️ Servings: 8

Ingredients

• 1/3 cup of Heavy Cream- 0g sugar, 5.5g carbohydrates
• 3/4 cup of Half and Half- 6g sugar, 3g carbohydrates
• 4oz Sugar Free Cool Whip (1/2 small container) - 0g sugar, 37.5g carbohydrates
• 1.5oz box (small box) of Sugar Free Instant Chocolate Pudding- 0g sugar, 32g carbohydrates
• 1 Pecan Pie Crust- 24g sugar, 72g carbohydrates

Directions

1. The total pie has 30g of sugar and 149.50g of carboydrates. So if you cut the pie into 8 equal slices, that would come to 3.75g of sugar and 18.69g carbohydrates per slice. If you decided to not eat the crust, your sugar intake would be .75 gram per slice and the carborytrates would be 9.69g per slice. Based on your objective, you could use only heavy whipping cream and no half and half to further reduce your sugar intake.
2. Mix all wet ingredients and the instant pudding until thoroughly mixed and a consistent color has been achieved. The heavy whipping cream causes the mixture to thicken the more you mix it. So, I’d recommend using an electric mixer. Once you are satisfied with the color, start mixing in the whipping cream until it has a consistent “chocolate” color thorough. Once your satisfied with the color, spoon the mixture into the pie crust, smooth the top to your liking, and then refrigerate for one hour before serving.

@ c066aac5:6a41a034

I work in the business world as a salesperson. I am frequently out and about in the community trying to make friends, connect with people who I can help, and ultimately grow my book of business. I have goals set by my employers and I aim to meet those expectations. Because of this, I find myself frequently under pressure to find ways to produce. This often leads to me being disappointed in myself; my sales cycles are long and I lose more deals than I win. My Dad often reminds me that How to Win Friends and Influence People has all the secrets of sales I'll ever need, but I still end up wishing I could find that secret edge to out-do the competition. That's where the watch temptation comes in.

I frequently see a luxurious timepiece on the left wrist of my peers and elder-statesmen closers. Rolex, Omega, Patek, a whole world of $10k minimum machines. It comes across as a power-move, a symbol of status that is hard to ignore. It sends a message that the bearer's time is more valuable than that of other people. It makes me think "if this person is wearing that watch, that means they're great at what they do." The ultimate investment in one's self.

As a newly married man expecting a child, it is hard for me to stomach such a purchase. My wife has supported the idea of me potentially getting such a timepiece; as much as it tickles my fancy, I'd rather put my capital towards things that further my family than my clout. One of the things that struck me was a statement made by an investment advisor in my Kiwanis club: "A watch is a purchase, not an investment."

What a true statement! His words helped me escape my short-lived delusions. That said, I still look at watches sometimes on the internet (The Omega No Time to Die watch is sleek looking). One day, I found myself looking at houses online shortly after looking at watches online. Then it hit me: how many purchases are being marketed as investments in this era? A Rolex is a supposed investment in your career, not just a luxury timepiece. A house is a mechanism for monetary growth, not an attainable home to be enjoyed by a family. A college degree is an investment for your future, not a vehicle for building upon passions.

The Bitcoiners will repeat the phrase "fix the money, fix the world" in harmonious chorus to address the concern I have laid out in this article. Ultimately, I leave you with this reminder: don't let the world pass off things that should be inconsequential purchases as investments with ROIs. I believe the only true investment one can make is into the people around them; that will yield the greatest rewards for the soul.

@ 6e64b83c:94102ee8

• Demo: https://blog.nostrize.me
• Source code: nostr-static

Prerequisites

Before using nostr-static, you'll need:

1. Nostr Articles: You can either:
2. Create new articles using platforms like yakihonne.com or habla.news
3. Find existing articles on Nostr

4. Copy the naddr string from the article (usually can be found in the address bar)

5. Author Profiles: For each article's author:

6. Copy their public key (pubkey)
7. Visit njump.me/npub1xxxxx (replace with the actual pubkey)
8. Copy the nprofile string from the page

These identifiers (naddr for articles and nprofile for authors) are essential for the tool to fetch and display your content correctly.

Features

Core Functionality

• Index Page: A homepage featuring your blog's title, logo, article summaries, and tags
• Article Pages: Individual pages for each article, including:
• Title and logo
• Article summary
• Full content
• Tags
• Comments (via ZapThreads integration)

Social Features

• Comments: Integrated with ZapThreads for decentralized commenting
• Nostr Connect: Seamless integration with window.nostr.js (wnj), supporting NIP-46 bunker connect

Content Organization

• Tag Pages: Browse articles filtered by specific tags
• Profile Pages: View articles from specific authors
• Manual Curation: Select and order articles by adding their naddr strings (see NIP-19)

Customization Options

• Themes: Choose between dark and light mode
• Branding:
• Custom logo
• Custom blog title
• Network: Specify your preferred Nostr relays

Technical Requirements

• Profile Format: Authors must be added in nprofile format (see NIP-19) for consistency
• Automatic Updates: Built-in scripts for:
• Windows Task Scheduler
• Unix/Linux cron jobs

Getting Started

1. Fork and Clone:
2. Fork this repository to your GitHub account
3. Clone it to your local machine or use GitHub Codespaces for a cloud-based development environment

4. Watch this quick tutorial to learn more about GitHub Codespaces

5. Configuration: Set up your config.yaml file with:

6. Blog title and logo
7. Theme preference
8. Relay list
9. Article naddr strings

10. Author nprofile strings

11. Content Selection: Add your desired articles by including their naddr strings in the configuration

12. Author Selection: You have to add the nprofile strings of the articles. This is needed for URL consistancy.

13. Build & Run: Follow the instruction in the README at https://github.com/dhalsim/nostr-static

14. Deployment: Choose your preferred static hosting service and deploy the generated HTML files

15. Updates: Set up automatic updates using the provided scripts for your operating system (For github pages)

Deployment Options

GitHub Pages (Recommended)

GitHub Pages provides free hosting for static websites. Here's how to set it up:

1. Enable GitHub Pages:
2. Go to your repository's Settings
3. Navigate to "Pages" in the menu
4. Under "Build and deployment" > "Source", select "GitHub Actions"
5. Enable Actions by following the GitHub Actions settings guide

6. Go to the "Actions" tab in the top menu. If you see the message "Workflows aren't being run on this forked repository", click the "I understand my workflows, go ahead and enable them" button

7. Custom Domain Setup:

8. Purchase a domain from your preferred domain registrar
9. Create a CNAME record in your domain's DNS settings:
   • Type: CNAME
   • Name: @ or www or a subdomain you prefer (depending on your preference)
   • Value: YOUR_GITHUB_USERNAME.github.io
10. In your repository's GitHub Pages settings:
    • Enter your custom domain in the "Custom domain" field
    • Check "Enforce HTTPS" for secure connections
11. Wait for DNS propagation (can take up to 24 hours)
12. Your site will be available at your custom domain

Other Hosting Options

You can also deploy your static site to any hosting service that supports static websites, such as: - Netlify - Vercel - Cloudflare Pages - Amazon S3 - Any traditional web hosting service

Why nostr-static?

nostr-static offers a unique solution for bloggers who want to leverage Nostr's decentralized content while maintaining a traditional web presence. It combines the best of both worlds:

• Decentralized Content: Your articles live on the Nostr network
• Traditional Web Presence: A familiar blog interface for your readers
• Easy Maintenance: Simple configuration and automatic updates
• Flexible Hosting: Deploy anywhere that supports static websites
• Social interactions: Leverage nostr for comments

Conclusion

nostr-static makes it easy to create a professional blog from your Nostr long-form content. Whether you're a seasoned Nostr user or new to the ecosystem, this tool provides a straightforward way to share your content with both the Nostr community and traditional web users.

Start your Nostr-powered blog today by visiting the demo and exploring the possibilities!

@ 41e6f20b:06049e45

Let me tell you a beautiful story. Last night, during the speakers' dinner at Monerotopia, the waitress was collecting tiny tips in Mexican pesos. I asked her, "Do you really want to earn tips seriously?" I then showed her how to set up a Cake Wallet, and she started collecting tips in Monero, reaching 0.9 XMR. Of course, she wanted to cash out to fiat immediately, but it solved a real problem for her: making more money. That amount was something she would never have earned in a single workday. We kept talking, and I promised to give her Zoom workshops. What can I say? I love people, and that's why I'm a natural orange-piller.

@ c4b5369a:b812dbd6

Offline transactions with Cashu

Over the past few weeks, I've been busy implementing offline capabilities into nutstash. I think this is one of the key value propositions of ecash, beinga a bearer instrument that can be used without internet access. It does however come with limitations, which can lead to a bit of confusion. I hope this article will clear some of these questions up for you!

What is ecash/Cashu?

Ecash is the first cryptocurrency ever invented. It was created by David Chaum in 1983. It uses a blind signature scheme, which allows users to prove ownership of a token without revealing a link to its origin. These tokens are what we call ecash. They are bearer instruments, meaning that anyone who possesses a copy of them, is considered the owner.

Cashu is an implementation of ecash, built to tightly interact with Bitcoin, more specifically the Bitcoin lightning network. In the Cashu ecosystem, Mints are the gateway to the lightning network. They provide the infrastructure to access the lightning network, pay invoices and receive payments. Instead of relying on a traditional ledger scheme like other custodians do, the mint issues ecash tokens, to represent the value held by the users.

How do normal Cashu transactions work?

A Cashu transaction happens when the sender gives a copy of his ecash token to the receiver. This can happen by any means imaginable. You could send the token through email, messenger, or even by pidgeon. One of the common ways to transfer ecash is via QR code.

The transaction is however not finalized just yet! In order to make sure the sender cannot double-spend their copy of the token, the receiver must do what we call a swap. A swap is essentially exchanging an ecash token for a new one at the mint, invalidating the old token in the process. This ensures that the sender can no longer use the same token to spend elsewhere, and the value has been transferred to the receiver.

What about offline transactions?

Sending offline

Sending offline is very simple. The ecash tokens are stored on your device. Thus, no internet connection is required to access them. You can litteraly just take them, and give them to someone. The most convenient way is usually through a local transmission protocol, like NFC, QR code, Bluetooth, etc.

The one thing to consider when sending offline is that ecash tokens come in form of "coins" or "notes". The technical term we use in Cashu is Proof. It "proofs" to the mint that you own a certain amount of value. Since these proofs have a fixed value attached to them, much like UTXOs in Bitcoin do, you would need proofs with a value that matches what you want to send. You can mix and match multiple proofs together to create a token that matches the amount you want to send. But, if you don't have proofs that match the amount, you would need to go online and swap for the needed proofs at the mint.

Another limitation is, that you cannot create custom proofs offline. For example, if you would want to lock the ecash to a certain pubkey, or add a timelock to the proof, you would need to go online and create a new custom proof at the mint.

Receiving offline

You might think: well, if I trust the sender, I don't need to be swapping the token right away!

You're absolutely correct. If you trust the sender, you can simply accept their ecash token without needing to swap it immediately.

This is already really useful, since it gives you a way to receive a payment from a friend or close aquaintance without having to worry about connectivity. It's almost just like physical cash!

It does however not work if the sender is untrusted. We have to use a different scheme to be able to receive payments from someone we don't trust.

Receiving offline from an untrusted sender

To be able to receive payments from an untrusted sender, we need the sender to create a custom proof for us. As we've seen before, this requires the sender to go online.

The sender needs to create a token that has the following properties, so that the receciver can verify it offline:

• It must be locked to ONLY the receiver's public key
• It must include an offline signature proof (DLEQ proof)
• If it contains a timelock & refund clause, it must be set to a time in the future that is acceptable for the receiver
• It cannot contain duplicate proofs (double-spend)
• It cannot contain proofs that the receiver has already received before (double-spend)

If all of these conditions are met, then the receiver can verify the proof offline and accept the payment. This allows us to receive payments from anyone, even if we don't trust them.

At first glance, this scheme seems kinda useless. It requires the sender to go online, which defeats the purpose of having an offline payment system.

I beleive there are a couple of ways this scheme might be useful nonetheless:

1. Offline vending machines: Imagine you have an offline vending machine that accepts payments from anyone. The vending machine could use this scheme to verify payments without needing to go online itself. We can assume that the sender is able to go online and create a valid token, but the receiver doesn't need to be online to verify it.

2. Offline marketplaces: Imagine you have an offline marketplace where buyers and sellers can trade goods and services. Before going to the marketplace the sender already knows where he will be spending the money. The sender could create a valid token before going to the marketplace, using the merchants public key as a lock, and adding a refund clause to redeem any unspent ecash after it expires. In this case, neither the sender nor the receiver needs to go online to complete the transaction.

How to use this

Pretty much all cashu wallets allow you to send tokens offline. This is because all that the wallet needs to do is to look if it can create the desired amount from the proofs stored locally. If yes, it will automatically create the token offline.

Receiving offline tokens is currently only supported by nutstash (experimental).

To create an offline receivable token, the sender needs to lock it to the receiver's public key. Currently there is no refund clause! So be careful that you don't get accidentally locked out of your funds!

The receiver can then inspect the token and decide if it is safe to accept without a swap. If all checks are green, they can accept the token offline without trusting the sender.

The receiver will see the unswapped tokens on the wallet homescreen. They will need to manually swap them later when they are online again.

Later when the receiver is online again, they can swap the token for a fresh one.

Summary

We learned that offline transactions are possible with ecash, but there are some limitations. It either requires trusting the sender, or relying on either the sender or receiver to be online to verify the tokens, or create tokens that can be verified offline by the receiver.

I hope this short article was helpful in understanding how ecash works and its potential for offline transactions.

Cheers,

Gandlaf

@ 418a17eb:b64b2b3a

In today’s world, many people chase after money. We often think that wealth equals success and happiness. But if we look closer, we see that money is just a tool. The real goal is freedom.

Money helps us access resources and experiences. It can open doors. But the constant pursuit of wealth can trap us. We may find ourselves stressed, competing with others, and feeling unfulfilled. The more we chase money, the more we might lose sight of what truly matters.

Freedom, on the other hand, is about choice. It’s the ability to live life on our own terms. When we prioritize freedom, we can follow our passions and build meaningful relationships. We can spend our time on what we love, rather than being tied down by financial worries.

True fulfillment comes from this freedom. It allows us to define success for ourselves. When we embrace freedom, we become more resilient and creative. We connect more deeply with ourselves and others. This sense of purpose often brings more happiness than money ever could.

In the end, money isn’t the ultimate goal. It’s freedom that truly matters. By focusing on living authentically and making choices that resonate with us, we can create a life filled with meaning and joy.

@ 4ba8e86d:89d32de4

Tutorial feito por Grom mestre⚡poste original abaixo:

http://xh6liiypqffzwnu5734ucwps37tn2g6npthvugz3gdoqpikujju525yd.onion/240277/tutorial-criando-e-acessando-sua-conta-de-email-pela-i2p?show=240277#q240277

Bom dia/tarde/noite a todos os camaradas. Seguindo a nossa série de tutoriais referentes a tecnologias essenciais para a segurança e o anonimato dos usuários, sendo as primeiras a openPGP e a I2P, lhes apresento mais uma opção para expandir os seus conhecimentos da DW. Muitos devem conhecer os serviços de mail na onion como DNMX e mail2tor, mas e que tal um serviço de email pela I2P. Nesse tutorial eu vou mostrar a vocês como criar a sua primeira conta no hq.postman.i2p e a acessar essa conta.

É importante que vocês tenham lido a minha primeira série de tutoriais a respeito de como instalar, configurar e navegar pela I2P nostr:nevent1qqsyjcz2w0e6d6dcdeprhuuarw4aqkw730y542dzlwxwssneq3mwpaspz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygzt4r5x6tvh39kujvmu8egqdyvf84e3w4e0mq0ckswamfwcn5eduspsgqqqqqqsyp5vcq Esse tutorial é um pré-requisito para o seguinte e portanto recomendo que leia-os antes de prosseguir com o seguinte tutorial. O tutorial de Kleopatra nostr:nevent1qqs8h7vsn5j6qh35949sa60dms4fneussmv9jd76n24lsmtz24k0xlqzyp9636rd9ktcjmwfxd7ru5qxjxyn6uch2uhas8utg8wa5hvf6vk7gqcyqqqqqqgecq8f7 é complementar dado que é extremamente recomendado assinar e criptografar as mensagens que seguem por emails pela DW. Sem mais delongas, vamos ao tutorial de fato.

1. Criando uma conta de email no hq.postman

Relembrando: Esse tutorial considera que você já tenha acesso à I2P. Entre no seu navegador e acesse o endereço hq.postman.i2p. O roteador provavelmente já contém esse endereço no seu addressbook e não haverá a necessidade de inserir o endereço b32 completo. Após entrar no site vá para a página '1 - Creating a mailbox' https://image.nostr.build/d850379fe315d2abab71430949b06d3fa49366d91df4c9b00a4a8367d53fcca3.jpg

Nessa página, insira as credenciais de sua preferências nos campos do formulário abaixo. Lembre-se que o seu endereço de email aceita apenas letras e números. Clique em 'Proceed' depois que preencher todos os campos. https://image.nostr.build/670dfda7264db393e48391f217e60a2eb87d85c2729360c8ef6fe0cf52508ab4.jpg

Uma página vai aparecer pedindo para confirmar as credenciais da sua nova conta. Se tudo estiver certo apenas clique em 'Confirm and Create Mailbox'. Se tudo ocorrer como conforme haverá uma confirmação de que a sua nova conta foi criada com sucesso. Após isso aguarde por volta de 5 minutos antes de tentar acessá-la, para que haja tempo suficiente para o servidor atualizar o banco de dados. https://image.nostr.build/ec58fb826bffa60791fedfd9c89a25d592ac3d11645b270c936c60a7c59c067f.jpg https://image.nostr.build/a2b7710d1e3cbb36431acb9055fd62937986b4da4b1a1bbb06d3f3cb1f544fd3.jpg

Pronto! Sua nova conta de email na I2P foi criada. Agora vamos para a próxima etapa: como acessar a sua conta via um cliente de email.

2. Configurando os túneis cliente de SMTP e POP3

O hq.postman não possui um cliente web que nos permite acessar a nossa conta pelo navegador. Para isso precisamos usar um cliente como Thunderbird e configurar os túneis cliente no I2Pd que serão necessários para o Thunderbird se comunicar com o servidor pela I2P.

Caso não tenha instalado o Thunderbird ainda, faça-o agora antes de prosseguir.

Vamos configurar os túneis cliente do servidor de email no nosso roteador. Para isso abra um terminal ou o seu gestor de arquivos e vá para a pasta de configuração de túneis do I2P. Em Linux esse diretório se localiza em /etc/i2pd/tunnels.d. Em Windows, essa pasta se localiza em C:\users\user\APPDATA\i2pd. Na pasta tunnels.d crie dois arquivos: smtp.postman.conf e pop-postman.conf. Lembre-se que em Linux você precisa de permissões de root para escrever na pasta de configuração. Use o comando sudoedit para isso.

Edite-os conforme as imagens a seguir:

Arquivo pop-postman.conf https://image.nostr.build/7e03505c8bc3b632ca5db1f8eaefc6cecb4743cd2096d211dd90bbdc16fe2593.jpg

Arquivo smtp-postman.conf https://image.nostr.build/2d06c021841dedd6000c9fc2a641ed519b3be3c6125000b188842cd0a5af3d16.jpg

Salve os arquivos e reinicie o serviço do I2Pd. Em Linux isso é feito pelo comando: sudo systemctl restart i2pd Entre no Webconsole do I2Pd pelo navegador (localhost:7070) e na seção I2P Tunnels, verifique se os túneis pop-postman e smtp-postman foram criados, caso contrário verifique se há algum erro nos arquivos e reinicie o serviço.

Com os túneis cliente criados, vamos agora configurar o Thunderbird

3. Configurando o Thunderbird para acessar a nossa conta

Abra o Thunderbird e clique em criar uma nova conta de email. Se você não tiver nenhum conta previamente presente nele você vai ser diretamente recebido pela janela de criação de conta a seguir. https://image.nostr.build/e9509d7bd30623716ef9adcad76c1d465f5bc3d5840e0c35fe4faa85740f41b4.jpg https://image.nostr.build/688b59b8352a17389902ec1e99d7484e310d7d287491b34f562b8cdd9dbe8a99.jpg

Coloque as suas credenciais, mas não clique ainda em Continuar. Clique antes em Configure Manually, já que precisamos configurar manualmente os servidores de SMTP e POP3 para, respectivamente, enviar e receber mensagens.

Preencha os campos como na imagem a seguir. Detalhe: Não coloque o seu endereço completo com o @mail.i2p, apenas o nome da sua conta. https://image.nostr.build/4610b0315c0a3b741965d3d7c1e4aff6425a167297e323ba8490f4325f40cdcc.jpg

Clique em Re-test para verificar a integridade da conexão. Se tudo estiver certo uma mensagem irá aparecer avisando que as configurações do servidores estão corretas. Clique em Done assim que estiver pronto para prosseguir. https://image.nostr.build/8a47bb292f94b0d9d474d4d4a134f8d73afb84ecf1d4c0a7eb6366d46bf3973a.jpg

A seguinte mensagem vai aparecer alertando que não estamos usando criptografia no envio das credenciais. Não há problema nenhum aqui, pois a I2P está garantindo toda a proteção e anonimato dos nossos dados, o que dispensa a necessidade de uso de TLS ou qualquer tecnologia similar nas camadas acima. Marque a opção 'I Understand the risks' e clique em 'Continue' https://image.nostr.build/9c1bf585248773297d2cb1d9705c1be3bd815e2be85d4342227f1db2f13a9cc6.jpg

E por fim, se tudo ocorreu como devido sua conta será criada com sucesso e você agora será capaz de enviar e receber emails pela I2P usando essa conta. https://image.nostr.build/8ba7f2c160453c9bfa172fa9a30b642a7ee9ae3eeb9b78b4dc24ce25aa2c7ecc.jpg

4. Observações e considerações finais

Como informado pelo próprio site do hq.postman, o domínio @mail.i2p serve apenas para emails enviados dentro da I2P. Emails enviados pela surface devem usar o domínio @i2pmai.org. É imprescindível que você saiba usar o PGP para assinar e criptografar as suas mensagens, dado que provavelmente as mensagens não são armazenadas de forma criptografada enquanto elas estão armazenadas no servidor. Como o protocolo POP3 delete as mensagens no imediato momento em que você as recebe, não há necessidade de fazer qualquer limpeza na sua conta de forma manual.

Por fim, espero que esse tutorial tenha sido útil para vocês. Que seu conhecimento tenha expandido ainda mais com as informações trazidas aqui. Até a próxima.

@ 177bfd16:347a07e4

So , you've battles through your way through countless Grunts , overcome the Team GO Rocket Leaders, and now you stand face to face with the big boss him self - Giovanni!

As of April 2025 , Giovanni is finishing his battles with Shadow Palkia.

Giovanni's Current Lineup (April 2025) First, know your enemy. Giovanni's team follows this structure:

Slot 1: Shadow Persian (Normal)

Slot 2: One of these three, chosen randomly:

Shadow Nidoking (Poison/Ground) Shadow Kingdra (Water/Dragon) Shadow Rhyperior (Rock/Ground)

Slot 3: Shadow Palkia (Water/Dragon) Remember, these are Shadow Pokémon – they hit harder than their normal counterparts!

Counter Strategy: Beating Giovanni Pokémon by Pokémon

Let's dive into the best counters for each potential opponent:

1. Vs. Shadow Persian (Normal)

Giovanni always leads with Persian. As a Normal-type, it's weak only to Fighting-type attacks.

Top Counters: Machamp, Lucario, Conkeldurr, Terrakion, Mega Blaziken, Mega Lucario.

Moves: Prioritize Fighting-type moves like Counter, Dynamic Punch, Aura Sphere, and Sacred Sword.

Tip: Lead with a strong Fighting-type. Moves like Lucario's Power-Up Punch or Machamp's Cross Chop charge quickly and are great for baiting Giovanni's shields early!

1. Vs. The Second Slot (Nidoking, Kingdra, or Rhyperior)

This is where things get unpredictable. You need Pokémon that can handle these potential threats:

Vs. Shadow Nidoking (Poison/Ground): Weak to Water, Ground, Ice, Psychic.

Counters: Kyogre (Primal/Shadow), Swampert (Mega), Groudon (Primal/Shadow), Mewtwo (Shadow), Excadrill. Water and Ground-types are prime choices.

Vs. Shadow Kingdra (Water/Dragon): Weak to Fairy, Dragon. Counters: Gardevoir (Mega), Togekiss, Xerneas. Fairy-types are excellent as they resist Dragon attacks while dealing super-effective damage. Dragon-types like Rayquaza or Palkia work but are risky.

Vs. Shadow Rhyperior (Rock/Ground): Double weak to Water and Grass! Also weak to Fighting, Ground, Ice, Steel.

Counters: Kyogre (Primal/Shadow), Swampert (Mega), Sceptile (Mega), Roserade. Your Fighting-type lead (if it survived Persian) can also do significant damage. Hit it hard with Water or Grass!

1. Vs. Shadow Palkia (Water/Dragon)

Giovanni's final Pokémon is the powerful Shadow Palkia. Like Kingdra, it's weak to Fairy and Dragon types.

Top Counters: Gardevoir (Mega), Togekiss, Xerneas. Again, Fairy-types are the safest and most reliable counters.

Dragon Counters (Use with Caution): Rayquaza (Mega), Palkia (Origin Forme), Dragonite, Dialga (Origin Forme).

Recommended Battle Teams for April 2025 Based on the counters, here are a few effective teams you can assemble:

Team 1 (Balanced):

Machamp (Counter / Cross Chop & Dynamic Punch)

Swampert (Mud Shot / Hydro Cannon & Earthquake)

Togekiss (Charm / Dazzling Gleam & Ancient Power)

Why it works: Covers all bases well with accessible Pokémon. Machamp handles Persian/shields, Swampert crushes Rhyperior/Nidoking, Togekiss tackles Kingdra/Palkia.

Team 2 (Legendary Power):

Lucario (Counter / Power-Up Punch & Aura Sphere)

Kyogre (Waterfall / Origin Pulse & Surf)

Xerneas (Geomancy / Moonblast & Close Combat)

Why it works: High-powered options. Lucario baits shields effectively, Kyogre dominates slot two's Ground/Rock types, Xerneas shreds the Dragons.

Team 3 (Mega Advantage):

Machamp (Counter / Cross Chop & DP)

Kyogre (Waterfall / Origin Pulse)

Mega Gardevoir (Charm / Dazzling Gleam & Shadow Ball)

Why it works: Uses a standard strong lead and mid-game counter, saving the Mega slot for Gardevoir to ensure a powerful finish against Palkia/Kingdra.

Essential Battle Tips Don't forget these crucial tactics:

The Switch Trick: Place your intended starting Pokémon (e.g., Machamp) in the second or third slot. Start the battle, then immediately switch to it. Giovanni will pause for a moment, letting you get in free hits!

Bait Those Shields: Use Pokémon with fast-charging Charged Moves, especially early on, to force Giovanni to waste his Protect Shields.

Power Up: Ensure your team is powered up significantly and consider unlocking second Charged Moves for better flexibility.

Don't Give Up: Giovanni is tough! It might take a few tries to get the right matchup against his second Pokémon. Learn from each attempt and adjust your team if needed.

Go show the boss who's the boss and claim your shadow Palkia . Good Luck, Trainer !

@ ec42c765:328c0600

2024年3月

フィリピンのセブ島へ旅行。初海外。

Nostrに投稿したらこんなリプライが

nostr:nevent1qqsff87kdxh6szf9pe3egtruwfz2uw09rzwr6zwpe7nxwtngmagrhhqc2qwq5

nostr:nevent1qqs9c8fcsw0mcrfuwuzceeq9jqg4exuncvhas5lhrvzpedeqhh30qkcstfluj

（ビットコイン関係なく普通の旅行のつもりで行ってた。というか常にビットコインのこと考えてるわけではないんだけど…）

そういえばフィリピンでビットコイン決済できるお店って多いのかな？

海外でビットコイン決済ってなんかかっこいいな！

やりたい！

---

ビットコイン決済してみよう！ in セブ島

BTCMap でビットコイン決済できるところを探す

本場はビットコインアイランドと言われてるボラカイ島みたいだけど

セブにもそれなりにあった！

なんでもいいからビットコイン決済したいだけなので近くて買いやすい店へ

いざタピオカミルクティー屋！

ちゃんとビットコインのステッカーが貼ってある！

つたない英語とGoogle翻訳を使ってビットコイン決済できるか店員に聞いたら

店員「ビットコインで支払いはできません」

（えーーーー、なんで…ステッカー貼ってあるやん…。）

まぁなんか知らんけどできないらしい。

店員に色々質問したかったけど質問する英語力もないのでする気が起きなかった

結局、せっかく店まで足を運んだので普通に現金でタピオカミルクティーを買った

タピオカミルクティー

話題になってた時も特に興味なくて飲んでなかったので、これが初タピオカミルクティーになった

法定通貨の味がした。

どこでもいいからなんでもいいから

海外でビットコイン決済してみたい

---

ビットコイン決済させてくれ！ in ボラカイ島

ビットコインアイランドと呼ばれるボラカイ島はめちゃくちゃビットコイン決済できるとこが多いらしい

でもやめてしまった店も多いらしい

でも300もあったならいくつかはできるとこあるやろ！

nostr:nevent1qqsw0n6utldy6y970wcmc6tymk20fdjxt6055890nh8sfjzt64989cslrvd9l

行くしかねぇ！

ビットコインアイランドへ

フィリピンの国内線だぁ

``` 行き方： Mactan-Cebu International Airport ↓飛行機 Godofredo P. Ramos Airport (Caticlan International Airport, Boracay Airport) ↓バスなど Caticlan フェリーターミナル ↓船 ボラカイ島

料金： 飛行機（受託手荷物付き） 往復 21,000円くらい 空港～ボラカイ島のホテルまで（バス、船、諸経費） 往復 3,300円くらい （klookからSouthwest Toursを利用）

このページが色々詳しい https://smaryu.com/column/d/91761/ ```

空港おりたらSouthwestのバスに乗る

事前にネットで申し込みをしている場合は5番窓口へ

港！

船！（めっちゃ速い）

ボラカイついた！

ボラカイ島の移動手段

セブの移動はgrabタクシーが使えるがボラカイにはない。

ネットで検索するとトライシクルという三輪タクシーがおすすめされている。 （トライシクル：開放的で風がきもちいい）

トライシクルの欠点はふっかけられるので値切り交渉をしないといけないところ。

最初に300phpくらいを提示され、行き先によるけど150phpくらいまでは下げられる。

これはこれで楽しい値切り交渉だけど、個人的にはトライシクルよりバスの方が気楽。

Hop On Hop Off バス：

https://www.hohoboracay.com/pass.php

一日乗り放題250phpなので往復や途中でどこか立ち寄ったりを考えるとお得。 バスは現金が使えないので事前にどこかでカードを買うか車内で買う。

私は何も知らずに乗って車内で乗務員さんから現金でカードを買った。

バスは狭い島内を数本がグルグル巡回してるので20～30分に1本くらいは来るイメージ。

逆にトライシクルは待たなくても捕まえればすぐに乗れるところがいいところかもしれない。

現実

ボラカイ島 BTC Map BTC決済できるとこめっちゃある

さっそく店に行く！

「bitcoin accepted here」のステッカーを見つける！

店員にビットコイン支払いできるか聞く！

できないと言われる！

もう一軒行く

「bitcoin accepted here」のステッカーを見つける

店員にビットコイン支払いできるか聞く

できないと言われる

5件くらいは回った

全部できない！

悲しい

で、ネットでビットコインアイランドで検索してみると

旅行日の一か月前くらいにアップロードされた動画があったので見てみた

要約 - ビットコイン決済はpouch.phというスタートアップ企業がボラカイ島の店にシステムを導入した - ビットコインアイランドとすることで観光客が10％～30％増加つまり数百～千人程度のビットコインユーザーが来ると考えた - しかし実際には3～5人だった - 結果的に200の店舗がビットコイン決済を導入しても使われたのはごく一部だった - ビットコイン決済があまり使われないので店員がやり方を忘れてしまった - 店は関心を失いpouchのアプリを消した

https://youtu.be/uaqx6794ipc?si=Afq58BowY1ZrkwaQ

なるほどね～

しゃあないわ

聖地巡礼

動画内でpouchのオフィスだったところが紹介されていた

これは半年以上前の画像らしい

現在はオフィスが閉鎖されビットコインの看板は色あせている おもしろいからここに行ってみよう！となった

で行ってみた

看板の色、更に薄くなってね！？

記念撮影 これはこれで楽しかった

場所はこの辺

https://maps.app.goo.gl/WhpEV35xjmUw367A8

ボラカイ島の中心部の結構いいとこ

みんな～ビットコイン（の残骸）の聖地巡礼、行こうぜ！

最後の店

Nattoさんから情報が

なんかあんまりネットでも今年になってからの情報はないような…https://t.co/hiO2R28sfO

ここは比較的最近…？https://t.co/CHLGZuUz04

— Natto (@madeofsoya) March 22, 2024

もうこれで最後だと思ってダメもとで行ってみた なんだろうアジア料理屋さん？

もはや信頼度0の「bitcoin accepted here」

ビットコイン払いできますか？

店員「できますよ」

え？ほんとに？ビットコイン払いできる？

店員「できます」

できる！！！！

なんかできるらしい。

適当に商品を注文して

印刷されたQRコードを出されたので読み取る

ここでスマートに決済できればよかったのだが結構慌てた

自分は英語がわからないし相手はビットコインがわからない

それにビットコイン決済は日本で１回したことがあるだけだった どうもライトニングアドレスのようだ

送金額はこちらで指定しないといけない

店員はフィリピンペソ建ての金額しか教えてくれない

何sats送ればいいのか分からない

ここでめっちゃ混乱した

でもウォレットの設定変えればいいと気付いた

普段円建てにしているのをフィリピンペソ建てに変更すればいいだけだった

設定を変更したら相手が提示している金額を入力して送金

送金は2、3秒で完了した

やった！

海外でビットコイン決済したぞ！

ログ

PORK CHAR SIU BUN とかいうやつを買った 普通にめっちゃおいしかった

なんかビットコイン決済できることにビビッて焦って一品しか注文しなかったけどもっと頼めばよかった

ここです。みなさん行ってください。

Bunbun Boracay

https://maps.app.goo.gl/DX8UWM8Y6sEtzYyK6

めでたしめでたし

---

以下、普通の観光写真

セブ島

ジンベエザメと泳いだ

スミロン島でシュノーケリング

市場の路地裏のちょっとしたダウンタウン？スラム？をビビりながら歩いた

ボホール島

なんか変な山

メガネザル

現地の子供が飛び込みを披露してくれた

ボラカイ島

ビーチ

夕日

藻

ボラカイ島にはいくつかビーチがあって宿が多いところに近い南西のビーチ、ホワイトビーチは藻が多かった（時期によるかも）

北側のプカシェルビーチは全然藻もなく、水も綺麗でめちゃくちゃよかった

プカシェルビーチ

---

おわり！

@ 3bf0c63f:aefa459d

How to do curation and businesses on Nostr

Suppose you want to start a Nostr business.

You might be tempted to make a closed platform that reuses Nostr identities and grabs (some) content from the external Nostr network, only to imprison it inside your thing -- and then you're going to run an amazing AI-powered algorithm on that content and "surface" only the best stuff and people will flock to your app.

This will be specially good if you're going after one of the many unexplored niches of Nostr in which reading immediately from people you know doesn't work as you generally want to discover new things from the outer world, such as:

• food recipe sharing;
• sharing of long articles about varying topics;
• markets for used goods;
• freelancer work and job offers;
• specific in-game lobbies and matchmaking;
• directories of accredited professionals;
• sharing of original music, drawings and other artistic creations;
• restaurant recommendations
• and so on.

But that is not the correct approach and damages the freedom and interoperability of Nostr, posing a centralization threat to the protocol. Even if it "works" and your business is incredibly successful it will just enshrine you as the head of a platform that controls users and thus is prone to all the bad things that happen to all these platforms. Your company will start to display ads and shape the public discourse, you'll need a big legal team, the FBI will talk to you, advertisers will play a big role and so on.

If you are interested in Nostr today that must be because you appreciate the fact that it is not owned by any companies, so it's safe to assume you don't want to be that company that owns it. So what should you do instead? Here's an idea in two steps:

1. Write a Nostr client tailored to the niche you want to cover

If it's a music sharing thing, then the client will have a way to play the audio and so on; if it's a restaurant sharing it will have maps with the locations of the restaurants or whatever, you get the idea. Hopefully there will be a NIP or a NUD specifying how to create and interact with events relating to this niche, or you will write or contribute with the creation of one, because without interoperability this can't be Nostr.

The client should work independently of any special backend requirements and ideally be open-source. It should have a way for users to configure to which relays they want to connect to see "global" content -- i.e., they might want to connect to wss://nostr.chrysalisrecords.com/ to see only the latest music releases accredited by that label or to wss://nostr.indiemusic.com/ to get music from independent producers from that community.

1. Run a relay that does all the magic

This is where your value-adding capabilities come into play: if you have that magic sauce you should be able to apply it here. Your service -- let's call it wss://magicsaucemusic.com/ -- will charge people or do some KYM (know your music) validation or use some very advanced AI sorcery to filter out the spam and the garbage and display the best content to your users who will request the global feed from it (["REQ", "_", {}]), and this will cause people to want to publish to your relay while others will want to read from it.

You set your relay as the default option in the client and let things happen. Your relay is like your "website" and people are free to connect to it or not. You don't own the network, you're just competing against other websites on a leveled playing field, so you're not responsible for it. Users get seamless browsing across multiple websites, unified identities, a unified interface (that could be different in a different client) and social interaction capabilities that work in the same way for all, and they do not depend on you, therefore they're more likely to trust you.

---

Does this centralize the network still? But this a simple and easy way to go about the matter and scales well in all aspects.

Besides allowing users to connect to specific relays for getting a feed of curated content, such clients should also do all kinds of "social" (i.e. following, commenting etc) activities (if they choose to do that) using the outbox model -- i.e. if I find a musician I like under wss://magicsaucemusic.com and I decide to follow them I should keep getting updates from them even if they get banned from that relay and start publishing on wss://nos.lol or wss://relay.damus.io or whatever relay that doesn't even know anything about music.

The hardcoded defaults and manual typing of relay URLs can be annoying. But I think it works well at the current stage of Nostr development. Soon, though, we can create events that recommend other relays or share relay lists specific to each kind of activity so users can get in-app suggestions of relays their friends are using to get their music from and so on. That kind of stuff can go a long way.

@ ee11a5df:b76c4e49

Bye-Bye Reply Guy

There is a camp of nostr developers that believe spam filtering needs to be done by relays. Or at the very least by DVMs. I concur. In this way, once you configure what you want to see, it applies to all nostr clients.

But we are not there yet.

In the mean time we have ReplyGuy, and gossip needed some changes to deal with it.

Strategies in Short

1. WEB OF TRUST: Only accept events from people you follow, or people they follow - this avoids new people entirely until somebody else that you follow friends them first, which is too restrictive for some people.
2. TRUSTED RELAYS: Allow every post from relays that you trust to do good spam filtering.
3. REJECT FRESH PUBKEYS: Only accept events from people you have seen before - this allows you to find new people, but you will miss their very first post (their second post must count as someone you have seen before, even if you discarded the first post)
4. PATTERN MATCHING: Scan for known spam phrases and words and block those events, either on content or metadata or both or more.
5. TIE-IN TO EXTERNAL SYSTEMS: Require a valid NIP-05, or other nostr event binding their identity to some external identity
6. PROOF OF WORK: Require a minimum proof-of-work

All of these strategies are useful, but they have to be combined properly.

filter.rhai

Gossip loads a file called "filter.rhai" in your gossip directory if it exists. It must be a Rhai language script that meets certain requirements (see the example in the gossip source code directory). Then it applies it to filter spam.

This spam filtering code is being updated currently. It is not even on unstable yet, but it will be there probably tomorrow sometime. Then to master. Eventually to a release.

Here is an example using all of the techniques listed above:

```rhai // This is a sample spam filtering script for the gossip nostr // client. The language is called Rhai, details are at: // https://rhai.rs/book/ // // For gossip to find your spam filtering script, put it in // your gossip profile directory. See // https://docs.rs/dirs/latest/dirs/fn.data_dir.html // to find the base directory. A subdirectory "gossip" is your // gossip data directory which for most people is their profile // directory too. (Note: if you use a GOSSIP_PROFILE, you'll // need to put it one directory deeper into that profile // directory). // // This filter is used to filter out and refuse to process // incoming events as they flow in from relays, and also to // filter which events get/ displayed in certain circumstances. // It is only run on feed-displayable event kinds, and only by // authors you are not following. In case of error, nothing is // filtered. // // You must define a function called 'filter' which returns one // of these constant values: // DENY (the event is filtered out) // ALLOW (the event is allowed through) // MUTE (the event is filtered out, and the author is // automatically muted) // // Your script will be provided the following global variables: // 'caller' - a string that is one of "Process", // "Thread", "Inbox" or "Global" indicating // which part of the code is running your // script // 'content' - the event content as a string // 'id' - the event ID, as a hex string // 'kind' - the event kind as an integer // 'muted' - if the author is in your mute list // 'name' - if we have it, the name of the author // (or your petname), else an empty string // 'nip05valid' - whether nip05 is valid for the author, // as a boolean // 'pow' - the Proof of Work on the event // 'pubkey' - the event author public key, as a hex // string // 'seconds_known' - the number of seconds that the author // of the event has been known to gossip // 'spamsafe' - true only if the event came in from a // relay marked as SpamSafe during Process // (even if the global setting for SpamSafe // is off)

fn filter() {

// Show spam on global
// (global events are ephemeral; these won't grow the
// database)
if caller=="Global" {
    return ALLOW;
}

// Block ReplyGuy
if name.contains("ReplyGuy") || name.contains("ReplyGal") {
    return DENY;
}

// Block known DM spam
// (giftwraps are unwrapped before the content is passed to
//  this script)
if content.to_lower().contains(
  "Mr. Gift and Mrs. Wrap under the tree, KISSING!"
) {
    return DENY;
}

// Reject events from new pubkeys, unless they have a high
// PoW or we somehow already have a nip05valid for them
//
// If this turns out to be a legit person, we will start
// hearing their events 2 seconds from now, so we will
// only miss their very first event.
if seconds_known <= 2 && pow < 25 && !nip05valid {
    return DENY;
}

// Mute offensive people
if content.to_lower().contains(" kike") ||
    content.to_lower().contains("kike ") ||
    content.to_lower().contains(" nigger") ||
    content.to_lower().contains("nigger ")
{
    return MUTE;
}

// Reject events from muted people
//
// Gossip already does this internally, and since we are
// not Process, this is rather redundant. But this works
// as an example.
if muted {
    return DENY;
}

// Accept if the PoW is large enough
if pow >= 25 {
    return ALLOW;
}

// Accept if their NIP-05 is valid
if nip05valid {
    return ALLOW;
}

// Accept if the event came through a spamsafe relay
if spamsafe {
    return ALLOW;
}

// Reject the rest
DENY

} ```

@ 3bf0c63f:aefa459d

Nostr: a quick introduction, attempt #2

Nostr doesn't subscribe to any ideals of "free speech" as these belong to the realm of politics and assume a big powerful government that enforces a common ruleupon everybody else.

Nostr instead is much simpler, it simply says that servers are private property and establishes a generalized framework for people to connect to all these servers, creating a true free market in the process. In other words, Nostr is the public road that each market participant can use to build their own store or visit others and use their services.

(Of course a road is never truly public, in normal cases it's ran by the government, in this case it relies upon the previous existence of the internet with all its quirks and chaos plus a hand of government control, but none of that matters for this explanation).

More concretely speaking, Nostr is just a set of definitions of the formats of the data that can be passed between participants and their expected order, i.e. messages between clients (i.e. the program that runs on a user computer) and relays (i.e. the program that runs on a publicly accessible computer, a "server", generally with a domain-name associated) over a type of TCP connection (WebSocket) with cryptographic signatures. This is what is called a "protocol" in this context, and upon that simple base multiple kinds of sub-protocols can be added, like a protocol for "public-square style microblogging", "semi-closed group chat" or, I don't know, "recipe sharing and feedback".

@ 0176967e:1e6f471e

Objavte, ako avatari a pseudonymné identity ovplyvňujú riadenie kryptokomunít a decentralizovaných organizácií (DAOs). V tejto prednáške sa zameriame na praktické fungovanie decentralizovaného rozhodovania, vytváranie a správu avatarových profilov, a ich rolu v online reputačných systémoch. Naučíte sa, ako si vytvoriť efektívny pseudonymný profil, zapojiť sa do rôznych krypto projektov a využiť svoje aktivity na zarábanie kryptomien. Preskúmame aj príklady úspešných projektov a stratégie, ktoré vám pomôžu zorientovať sa a uspieť v dynamickom svete decentralizovaných komunít.

@ 30ceb64e:7f08bdf5

Status: Draft
Author: TheWildHustle

Abstract

This NIP defines a framework for storing and sharing health and fitness profile data on Nostr. It establishes a set of standardized event kinds for individual health metrics, allowing applications to selectively access specific health information while preserving user control and privacy.

In this framework exists - NIP-101h.1 Weight using kind 1351 - NIP-101h.2 Height using kind 1352 - NIP-101h.3 Age using kind 1353 - NIP-101h.4 Gender using kind 1354 - NIP-101h.5 Fitness Level using kind 1355

Motivation

I want to build and support an ecosystem of health and fitness related nostr clients that have the ability to share and utilize a bunch of specific interoperable health metrics.

• Selective access - Applications can access only the data they need
• User control - Users can choose which metrics to share
• Interoperability - Different health applications can share data
• Privacy - Sensitive health information can be managed independently

Specification

Kind Number Range

Health profile metrics use the kind number range 1351-1399:

| Kind | Metric | | --------- | ---------------------------------- | | 1351 | Weight | | 1352 | Height | | 1353 | Age | | 1354 | Gender | | 1355 | Fitness Level | | 1356-1399 | Reserved for future health metrics |

Common Structure

All health metric events SHOULD follow these guidelines:

• The content field contains the primary value of the metric
• Required tags:
• ['t', 'health'] - For categorizing as health data
• ['t', metric-specific-tag] - For identifying the specific metric
• ['unit', unit-of-measurement] - When applicable
• Optional tags:
• ['converted_value', value, unit] - For providing alternative unit measurements
• ['timestamp', ISO8601-date] - When the metric was measured
• ['source', application-name] - The source of the measurement

Unit Handling

Health metrics often have multiple ways to be measured. To ensure interoperability:

• Where multiple units are possible, one standard unit SHOULD be chosen as canonical
• When using non-standard units, a converted_value tag SHOULD be included with the canonical unit
• Both the original and converted values should be provided for maximum compatibility

Client Implementation Guidelines

Clients implementing this NIP SHOULD:

• Allow users to explicitly choose which metrics to publish
• Support reading health metrics from other users when appropriate permissions exist
• Support updating metrics with new values over time
• Preserve tags they don't understand for future compatibility
• Support at least the canonical unit for each metric

Extensions

New health metrics can be proposed as extensions to this NIP using the format:

• NIP-101h.X where X is the metric number

Each extension MUST specify: - A unique kind number in the range 1351-1399 - The content format and meaning - Required and optional tags - Examples of valid events

Privacy Considerations

Health data is sensitive personal information. Clients implementing this NIP SHOULD:

• Make it clear to users when health data is being published
• Consider incorporating NIP-44 encryption for sensitive metrics
• Allow users to selectively share metrics with specific individuals
• Provide easy ways to delete previously published health data

---

NIP-101h.1: Weight

Description

This NIP defines the format for storing and sharing weight data on Nostr.

Event Kind: 1351

Content

The content field MUST contain the numeric weight value as a string.

Required Tags

• ['unit', 'kg' or 'lb'] - Unit of measurement
• ['t', 'health'] - Categorization tag
• ['t', 'weight'] - Specific metric tag

Optional Tags

• ['converted_value', value, unit] - Provides the weight in alternative units for interoperability
• ['timestamp', ISO8601 date] - When the weight was measured

Examples

json { "kind": 1351, "content": "70", "tags": [ ["unit", "kg"], ["t", "health"], ["t", "weight"] ] }

json { "kind": 1351, "content": "154", "tags": [ ["unit", "lb"], ["t", "health"], ["t", "weight"], ["converted_value", "69.85", "kg"] ] }

NIP-101h.2: Height

Status: Draft

Description

This NIP defines the format for storing and sharing height data on Nostr.

Event Kind: 1352

Content

The content field can use two formats: - For metric height: A string containing the numeric height value in centimeters (cm) - For imperial height: A JSON string with feet and inches properties

Required Tags

• ['t', 'health'] - Categorization tag
• ['t', 'height'] - Specific metric tag
• ['unit', 'cm' or 'imperial'] - Unit of measurement

Optional Tags

• ['converted_value', value, 'cm'] - Provides height in centimeters for interoperability when imperial is used
• ['timestamp', ISO8601-date] - When the height was measured

Examples

```jsx // Example 1: Metric height Apply to App.jsx

// Example 2: Imperial height with conversion Apply to App.jsx ```

Implementation Notes

• Centimeters (cm) is the canonical unit for height interoperability
• When using imperial units, a conversion to centimeters SHOULD be provided
• Height values SHOULD be positive integers
• For maximum compatibility, clients SHOULD support both formats

---

NIP-101h.3: Age

Status: Draft

Description

This NIP defines the format for storing and sharing age data on Nostr.

Event Kind: 1353

Content

The content field MUST contain the numeric age value as a string.

Required Tags

• ['unit', 'years'] - Unit of measurement
• ['t', 'health'] - Categorization tag
• ['t', 'age'] - Specific metric tag

Optional Tags

• ['timestamp', ISO8601-date] - When the age was recorded
• ['dob', ISO8601-date] - Date of birth (if the user chooses to share it)

Examples

```jsx // Example 1: Basic age Apply to App.jsx

// Example 2: Age with DOB Apply to App.jsx ```

Implementation Notes

• Age SHOULD be represented as a positive integer
• For privacy reasons, date of birth (dob) is optional
• Clients SHOULD consider updating age automatically if date of birth is known
• Age can be a sensitive metric and clients may want to consider encrypting this data

---

NIP-101h.4: Gender

Status: Draft

Description

This NIP defines the format for storing and sharing gender data on Nostr.

Event Kind: 1354

Content

The content field contains a string representing the user's gender.

Required Tags

• ['t', 'health'] - Categorization tag
• ['t', 'gender'] - Specific metric tag

Optional Tags

• ['timestamp', ISO8601-date] - When the gender was recorded
• ['preferred_pronouns', string] - User's preferred pronouns

Common Values

While any string value is permitted, the following common values are recommended for interoperability: - male - female - non-binary - other - prefer-not-to-say

Examples

```jsx // Example 1: Basic gender Apply to App.jsx

// Example 2: Gender with pronouns Apply to App.jsx ```

Implementation Notes

• Clients SHOULD allow free-form input for gender
• For maximum compatibility, clients SHOULD support the common values
• Gender is a sensitive personal attribute and clients SHOULD consider appropriate privacy controls
• Applications focusing on health metrics should be respectful of gender diversity

---

NIP-101h.5: Fitness Level

Status: Draft

Description

This NIP defines the format for storing and sharing fitness level data on Nostr.

Event Kind: 1355

Content

The content field contains a string representing the user's fitness level.

Required Tags

• ['t', 'health'] - Categorization tag
• ['t', 'fitness'] - Fitness category tag
• ['t', 'level'] - Specific metric tag

Optional Tags

• ['timestamp', ISO8601-date] - When the fitness level was recorded
• ['activity', activity-type] - Specific activity the fitness level relates to
• ['metrics', JSON-string] - Quantifiable fitness metrics used to determine level

Common Values

While any string value is permitted, the following common values are recommended for interoperability: - beginner - intermediate - advanced - elite - professional

Examples

```jsx // Example 1: Basic fitness level Apply to App.jsx

// Example 2: Activity-specific fitness level with metrics Apply to App.jsx ```

Implementation Notes

• Fitness level is subjective and may vary by activity
• The activity tag can be used to specify fitness level for different activities
• The metrics tag can provide objective measurements to support the fitness level
• Clients can extend this format to include activity-specific fitness assessments
• For general fitness apps, the simple beginner/intermediate/advanced scale is recommended

@ 0176967e:1e6f471e

Jan Kolčák pochádza zo stredného Slovenska a vystupuje pod umeleckým menom Deepologic. Hudbe sa venuje už viac než 10 rokov. Začínal ako DJ, ktorý s obľubou mixoval klubovú hudbu v štýloch deep-tech a afrohouse. Stále ho ťahalo tvoriť vlastnú hudbu, a preto sa začal vzdelávať v oblasti tvorby elektronickej hudby. Nakoniec vydal svoje prvé EP s názvom "Rezonancie". Učenie je pre neho celoživotný proces, a preto sa neustále zdokonaľuje v oblasti zvuku a kompozície, aby jeho skladby boli kvalitné na posluch aj v klube.

V roku 2023 si založil vlastnú značku EarsDeep Records, kde dáva príležitosť začínajúcim producentom. Jeho značku podporujú aj etablované mená slovenskej alternatívnej elektronickej scény. Jeho prioritou je sloboda a neškatulkovanie. Ako sa hovorí v jednej klasickej deephouseovej skladbe: "We are all equal in the house of deep." So slobodou ide ruka v ruke aj láska k novým technológiám, Bitcoinu a schopnosť udržať si v digitálnom svete prehľad, odstup a anonymitu.

V súčasnosti ďalej produkuje vlastnú hudbu, venuje sa DJingu a vedie podcast, kde zverejňuje svoje mixované sety. Na Lunarpunk festivale bude hrať DJ set tvorený vlastnou produkciou, ale aj skladby, ktoré sú blízke jeho srdcu.

Podcast Bandcamp Punk Nostr website alebo nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy88wumn8ghj7mn0wvhxcmmv9uq3xamnwvaz7tmsw4e8qmr9wpskwtn9wvhsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qyg8wumn8ghj7mn0wd68ytnddakj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qpqguvns4ld8k2f3sugel055w7eq8zeewq7mp6w2stpnt6j75z60z3swy7h05

@ 0176967e:1e6f471e

Workshop je zameraný pre všetkých, ktorí sa potýkajú s vysvetľovaním Bitcoinu svojej rodine, kamarátom, partnerom alebo kolegom. Pri námietkach z druhej strany väčšinou ideme do protiútoku a snažíme sa vytiahnuť tie najlepšie argumenty. Na tomto workshope vás naučím nový prístup k zvládaniu námietok a vyskúšate si ho aj v praxi. Know-how je aplikovateľné nie len na komunikáciu Bitcoinu ale aj pre zlepšenie vzťahov, pri výchove detí a celkovo pre lepší osobný život.

@ df478568:2a951e67

Welcome to Zap This Blog

Exploring Liberty With Fredom Tech

Zap This Blog! Shop Merch Nostree Cashu Cards

I can string some spaghetti HTMl code together here and there, but vibe coding gave me the confidence to look into the code injection section of the ghost Blog. As sudden as a new block, the Lex Friedman Robert Rodriguez interview, I had an epiphony when he asked Lex, "Do you consider yourself a creative person?" I aswered for myself, right away, emphatically yes. I just felt like I never knew what to do with this creative energy. Friedman hesitated and I was like..Wow...He has extreme creativity like Jocko Wilink has extreme disipline. If that guy has doubts, what the hell is stopping me from trying other stuff?

Rodriguez also claimed Four rooms was financial flop. I thought that movie was genius. I had no idea it failed financially. Nevertheless, it was not profitable. His advice was like Tony Robbins for film nerds. I learned about him in a film class I took in college. He was legendary for making a mobie for $7,000. My professor also said it was made for the Mexican VHS market, but I did not know he never sold it to that market. Robert Rodriguez tells the story 100X better, as you might expect a director of his caliber would. His advice hits like Tony Robbins, for film geeks. Here are a few gem quotes from the epiode.

"Sift through the ashes of your failures"

"Turn chicken shit into chicken salad."

"Follow your instinct. If it doesn't work, just go. Sometimes you need to slip on the first two rocks, so the key is in the ashes of failure because if I had an insticnt, that means I was on the right track. I didn't get the result I want. That's because the result might be something way bigger that I don't have the vision for and the universe is just pushing me that way."

"Turn chicken shit into chicken salad."

"If you have some kind of failure on something that you..., don't let it knock you down. Maybe in ten years they'll think it's great. I'm just going to commit to making a body of work, a body of work."

Rodriguez taught me what I already know. I am a creative person. I am just a body, punching keys on a keyboard, taking pictures, and semi-vibe-coding art. Maybe this is a shitty blog post today, but I write it anyway. Someone might look at it like I first looked at the math in the Bitcoin white paper and scan it with their eyeballs without really reading or understanding it. Most people on Substack probably don't want to read HTML, but maybe someone will come accross it one day and build something themselves they can find in the ashes of this code.

I once saw Brian Harrington say every bitcoiner is a business owner. If you have a bitcoin address, you can accept bitcoin. How does someone find you though? Are they really going to find your bitcoin address on GitHub? I'd bet 100 sats they won't. Nostr fixes this so I thought about integrating it into my Ghost Blog. I looked at the code injection section and let my muse do the typing. Actually, I let the Duck Duck AI chat do the vibe-coding. As it turns out, you an add a header and footer on Ghost in the code injection. It's just the same HTMl I used to make my MySpace page. Then I thought, what if someone couldn't afford a Start9 or didn't know how to vibe code on Duck Duck Go's free AI chat using Claude? What if, like Rodriguez suggests, I create a business card?

You could just copy my HTML and change my nostr links and pics to go to your nostr links and pics. You could publish that HTML into https://habla.news. Now you have an e-commerce site with a blog, a merch store, and your nostree. I don't know if this will work. This is the muse's hypothesis. I'm just writing the words down. You'll need to test this idea for yourself.

npub1marc26z8nh3xkj5rcx7ufkatvx6ueqhp5vfw9v5teq26z254renshtf3g0
marc26z@getalby.com
Zap This Blog!

@ 0176967e:1e6f471e

Ak ste v Bitcoine už nejaký ten rok, možno máte pocit, že už všetkému rozumiete a že vás nič neprekvapí. Viete čo je to peňaženka, čo je to seed a čo adresa, možno dokonca aj čo je to sha256. Ste si istí? Táto prednáška sa vám to pokúsi vyvrátiť. 🙂

@ a53364ff:e6ba5513

About

Bitcoin Core is an open source project which maintains and releases Bitcoin client software called “Bitcoin Core”.

It is a direct descendant of the original Bitcoin software client released by Satoshi Nakamoto after he published the famous Bitcoin whitepaper.

Bitcoin Core consists of both “full-node” software for fully validating the blockchain as well as a bitcoin wallet. The project also currently maintains related software such as the cryptography library libsecp256k1 and others located at GitHub.

Anyone can contribute to Bitcoin Core.

Team

The Bitcoin Core project has a large open source developer community with many casual contributors to the codebase. There are many more who contribute research, peer review, testing, documentation, and translation.

Maintainers

Project maintainers have commit access and are responsible for merging patches from contributors. They perform a janitorial role merging patches that the team agrees should be merged. They also act as a final check to ensure that patches are safe and in line with the project goals. The maintainers’ role is by agreement of project contributors.

Contributors

Everyone is free to propose code changes and to test, review and comment on open Pull Requests. Anyone who contributes code, review, test, translation or documentation to the Bitcoin Core project is considered a contributor. The release notes for each Bitcoin Core software release contain a credits section to recognize all those who have contributed to the project over the previous release cycle. A list of code contributors can be found on Github.

@ 0176967e:1e6f471e

Bojovať s rakovinou metabolickou metódou znamená použiť metabolizmus tela proti rakovine. Riadenie cukru a ketónov v krvi stravou a pohybom, časovanie rôznych typov cvičení, včasná kombinácia klasickej onko-liečby a hladovania. Ktoré vitamíny a suplementy prijímam a ktorým sa napríklad vyhýbam dajúc na rady mojej dietologičky z USA Miriam (ktorá sa špecializuje na rakovinu).

Hovori sa, že čo nemeriame, neriadime ... Ja som meral, veľa a dlho ... aj grafy budú ... aj sranda bude, hádam ... 😉

@ 6830c409:ff17c655

The story-telling method from Frank Daniel school - "Eight-sequence structure" is well utilized in this new movie in #prime - "Veera Dheera Sooran - Part 2". The name itself is kind of suspense. Because even if the name says "Part 2", this is the first part released in this story.

There are 8 shorter plots which has their own mini climaxes. The setup done in a plot will be resolved in another plot. In total, there will be 8 setups, 8 conflicts and 8 resolutions.

A beautiful way of telling a gripping story. For cinephiles in #Nostr, if you want to get a feel of the South Indian movies that has kind of a perfect blend of good content + a bit of over the top action, I would suggest this movie.

Note:

For Nostriches from the western hemisphere- #Bollywood - (#Hindi movies) is the movie industry started in #Bombay (#Mumbai), that has the stereotypical 'la la la' rain dance songs and mustache-less heroes. #Telugu movies (#Tollywood) are mostly over-the-top action where Newton and Einstein will probably commit suicide. #Malayalam movies (#Mollywood) is made with a miniscule budget with minimal over-the-top action and mostly content oriented movies. And then comes one of the best - #Tamil movies (#Kollywood - named after #Kodambakkam - a movie town in the city of Chennai down south), has the best of all the industries. A good blend of class, and mass elements.

Picture: https://www.flickr.com/photos/gforsythe/6926263837

@ 0176967e:1e6f471e

Predikčné trhy predstavujú praktický spôsob, ako môžeme nahliadnuť do budúcnosti bez nutnosti spoliehať sa na tradičné, často nepresné metódy, ako je veštenie z kávových zrniek. V prezentácii sa ponoríme do histórie a vývoja predikčných trhov, a popíšeme aký vplyv mali a majú na dostupnosť a kvalitu informácií pre širokú verejnosť, a ako menia trh s týmito informáciami. Pozrieme sa aj na to, ako tieto trhy umožňujú obyčajným ľuďom prístup k spoľahlivým predpovediam a ako môžu prispieť k lepšiemu rozhodovaniu v rôznych oblastiach života.

@ 0176967e:1e6f471e

AI hype vnímame asi všetci okolo nás — už takmer každá appka ponúka nejakú “AI fíčuru”, AI startupy raisujú stovky miliónov a Európa ako obvykle pracuje na regulovaní a našej ochrane pred nebezpečím umelej inteligencie. Pomaly sa ale ukazuje “ovocie” spojenia umelej inteligencie a človeka, kedy mnohí ľudia reportujú signifikantné zvýšenie produktivity v práci ako aj kreatívnych aktivitách (aj napriek tomu, že mnohí hardcore kreatívci by každého pri spomenutí skratky “AI” najradšej upálili). V prvej polovici prednášky sa pozrieme na to, akými rôznymi spôsobmi nám vie byť AI nápomocná, či už v práci alebo osobnom živote.

Umelé neuróny nám už vyskakujú pomaly aj z ovsených vločiek, no to ako sa k nám dostávajú sa veľmi líši. Hlavne v tom, či ich poskytujú firmy v zatvorených alebo open-source modeloch. V druhej polovici prednášky sa pozrieme na boom okolo otvorených AI modelov a ako ich vieme využiť.

@ fbf0e434:e1be6a39

Hackathon 概要

Hedera Hashathon: Nairobi Edition 近日圆满落幕，共有 223 名开发者参与，49 个项目通过审核。本次活动以线上形式举办，由 Kenya Tech Events、内罗毕证券交易所及虚拟资产商会共同支持，旨在推动本地创新并提升区块链技术在肯尼亚的应用水平。

黑客松围绕三大核心方向展开：AI 代理、资本市场和 Hedera Explorer。参与者基于 Hedera 区块链开发解决方案，针对性解决自动化、金融普惠及数字资产交互等领域的挑战。活动通过在线辅导和网络交流机会，充分展现了协作开发的重要性。

活动亮点当属在内罗毕大学举办的 Demo Day，入围决赛的团队现场展示创新方案并获颁奖项。尤其在资本市场方向的顶尖项目，将获得孵化支持及导师指导以推进后续开发。此次黑客松特别注重实际应用，凸显了区块链技术在重塑肯尼亚产业、推动技术进步并提升市场参与度方面的潜力。

Hackathon 获奖者

第一名

• **Hedgehog:** 一个使用Hedera网络上的代币化真实股票交易所股份作为抵押品的链上借贷协议。通过将股票抵押与区块链透明性相结合，确保了安全的去中心化借贷。

第二名

• **Orion:** 通过将NSE股票代币化为Hedera区块链上的资产，促进在肯尼亚的轻松股票交易。通过与Mpesa的集成简化了证券交易流程，实现高效的数字交易。

第三名

• **NSEChainBridge:** 一个基于区块链的平台，通过创新的代币解决方案增强了NSE股票作为数字代币的交易，提高股票交易的可达性和流动性。

第四名

• **HashGuard:** 一个使用Hedera Hashgraph技术的代币化微型保险平台，专为boda boda骑手提供。它提供了负担得起的即时保险，让不需要区块链专业知识的用户也能获得保险。

要查看完整项目列表，请访问 DoraHacks。

关于组织者

Hedera

Hedera是一个以速度、安全性和可扩展性著称的公共分布式账本平台。其hashgraph共识算法是一种权益证明的变体，提供了一种独特的分布式共识实现方式。Hedera活跃于多个行业领域，支持优先考虑透明度和效率的项目。该组织始终致力于推进去中心化网络的基础设施建设，促进全球范围内安全而高效的数字交易。

@ 0176967e:1e6f471e

Čo vznikne keď spojíš hru SNAKE zo starej Nokie 3310 a Bitcoin? - hra Chain Duel!

Jedna z najlepších implementácií funkcionality Lightning Networku a gamingu vo svete Bitcoinu.

Vyskúšať si ju môžete s kamošmi na tomto odkaze. Na stránke nájdeš aj základné pravidlá hry avšak odporúčame pravidlá pochopiť aj priamo hraním

Chain Duel si získava hromady fanúšikov po bitcoinových konferenciách po celom svete a práve na Lunarpunk festival ho prinesieme tiež.

Multiplayer 1v1 hra, kde nejde o náhodu, ale skill, vás dostane. Poďte si zmerať sily s ďalšími bitcoinermi a vyhrať okrem samotných satoshi rôzne iné ceny.

Príďte sa zúčastniť prvého oficiálneho Chain Duel turnaja na Slovensku!

Pre účasť na turnaji je potrebná registrácia dopredu.

@ 68c90cf3:99458f5c

Background

Last year I got interesting in running my own bitcoin node after reading others' experiences doing so. A couple of decades ago I ran my own Linux and Mac servers, and enjoyed building and maintaining them. I was by no means an expert sys admin, but had my share of cron jobs, scripts, and custom configuration files. While it was fun and educational, software updates and hardware upgrades often meant hours of restoring and troubleshooting my systems.

Fast forward to family and career (especially going into management) and I didn't have time for all that. Having things just work became more important than playing with the tech. As I got older, the more I appreciated K.I.S.S. (for those who don't know: Keep It Simple Stupid).

So when the idea of running a node came to mind, I explored the different options. I decided I needed a balance between a Raspberry Pi (possibly underpowered depending on use) and a full-blown Linux server (too complex and time-consuming to build and maintain). That led me to Umbrel OS, Start9, Casa OS, and similar platforms. Due to its simplicity (very plug and play), nice design, and being open source: GitHub), I chose Umbrel OS on a Beelink mini PC with 16GB of RAM and a 2TB NVMe internal drive. Though Umbrel OS is not very flexible and can't really be customized, its App Store made setting up a node (among other things) fairly easy, and it has been running smoothly since. Would the alternatives have been better? Perhaps, but so far I'm happy with my choice.

Server Setup

I'm also no expert in OpSec (I'd place myself in the category of somewhat above vague awareness). I wanted a secure way to connect to my Umbrel without punching holes in my router and forwarding ports. I chose Tailscale for this purpose. Those who are distrustful of corporate products might not like this option but again, balancing risk with convenience it seemed reasonable for my needs. If you're hiding state (or anti-state) secrets, extravagant wealth, or just adamant about privacy, you would probably want to go with an entirely different setup.

Once I had Tailscale installed on Umbrel OS, my mobile device and laptop, I could securely connect to the server from anywhere through a well designed browser UI. I then installed the following from the Umbrel App Store:

• Bitcoin Core
• Electrum Personal Server (Electrs)

At this point I could set wallets on my laptop (Sparrow) and phone (BlueWallet) to use my node. I then installed:

• Lightning Node (LND)
• Alby Hub

Alby Hub streamlines the process of opening and maintaining lightning channels, creating lightning wallets to send and receive sats, and zapping notes and users on Nostr. I have two main nsec accounts for Nostr and set up separate wallets on Alby Hub to track balances and transactions for each.

Other apps I installed on Umbrel OS:

• mempool
• Bitcoin Explorer
• LibreTranslate (some Nostr clients allow you to use your own translator)
• Public Pool

Public Pool allows me to connect Bitaxe solo miners (a.k.a. "lottery" miners) to my own mining pool for a (very) long shot at winning a Bitcoin block. It's also a great way to learn about mining, contribute to network decentralization, and generally tinker with electronics. Bitaxe miners are small open source single ASIC miners that you can run in your home with minimal technical knowledge and maintenance requirements.

Open Source Miners United (OSMU) is a great resource for anyone interesting in Bitaxe or other open source mining products (especially their Discord server).

Although Umbrel OS is more or less limited to running software in its App Store (or Community App Store, if you trust the developer), you can install the Portainer app and run Docker images. I know next to nothing about Docker but wanted to see what I might be able to do with it. I was also interested in the Haven Nostr relay and found that there was indeed a docker image for it.

As stated before, I didn't want to open my network to the outside, which meant I wouldn't be able to take advantage of all the features Haven offers (since other users wouldn't be able to access it). I would however be able to post notes to my relay, and use its "Blastr" feature to send my notes to other relays. After some trial and error I managed to get a Haven up and running in Portainer.

The upside of this setup is self-custody: being able to connect wallets to my own Bitcoin node, send and receive zaps with my own Lightning channel, solo mine with Bitaxe to my own pool, and send notes to my own Nostr relay. The downside is the lack of redundancy and uptime provided by major cloud services. You have to decide on your own comfort level. A solid internet connection and reliable power are definitely needed.

This article was written and published to Nostr with untype.app.

@ 826e9f89:ffc5c759

What follows began as snippets of conversations I have been having for years, on and off, here and there. It will likely eventually be collated into a piece I have been meaning to write on “payments” as a whole. I foolishly started writing this piece years ago, not realizing that the topic is gargantuan and for every week I spend writing it I have to add two weeks to my plan. That may or may not ever come to fruition, but in the meantime, Tether announced it was issuing on Taproot Assets and suddenly everybody is interested again. This is as good a catalyst as any to carve out my “stablecoin thesis”, such as it exists, from “payments”, and put it out there for comment and feedback.

In contrast to the “Bitcoiner take” I will shortly revert to, I invite the reader to keep the following potential counterargument in mind, which might variously be termed the “shitcoiner”, “realist”, or “cynical” take, depending on your perspective: that stablecoins have clear product-market-fit. Now, as a venture capitalist and professional thinkboi focusing on companies building on Bitcoin, I obviously think that not only is Bitcoin the best money ever invented and its monetization is pretty much inevitable, but that, furthermore, there is enormous, era-defining long-term potential for a range of industries in which Bitcoin is emerging as superior technology, even aside from its role as money. But in the interest not just of steelmanning but frankly just of honesty, I would grudgingly agree with the following assessment as of the time of writing: the applications of crypto (inclusive of Bitcoin but deliberately wider) that have found product-market-fit today, and that are not speculative bets on future development and adoption, are: Bitcoin as savings technology, mining as a means of monetizing energy production, and stablecoins.

I think there are two typical Bitcoiner objections to stablecoins of significantly greater importance than all others: that you shouldn’t be supporting dollar hegemony, and that you don’t need a blockchain. I will elaborate on each of these, and for the remainder of the post will aim to produce a synthesis of three superficially contrasting (or at least not obviously related) sources of inspiration: these objections, the realisation above that stablecoins just are useful, and some commentary on technical developments in Bitcoin and the broader space that I think inform where things are likely to go. As will become clear as the argument progresses, I actually think the outcome to which I am building up is where things have to go. I think the technical and economic incentives at play make this an inevitability rather than a “choice”, per se. Given my conclusion, which I will hold back for the time being, this is a fantastically good thing, hence I am motivated to write this post at all!

Objection 1: Dollar Hegemony

I list this objection first because there isn’t a huge amount to say about it. It is clearly a normative position, and while I more or less support it personally, I don’t think that it is material to the argument I am going on to make, so I don’t want to force it on the reader. While the case for this objection is probably obvious to this audience (isn’t the point of Bitcoin to destroy central banks, not further empower them?) I should at least offer the steelman that there is a link between this and the realist observation that stablecoins are useful. The reason they are useful is because people prefer the dollar to even shitter local fiat currencies. I don’t think it is particularly fruitful to say that they shouldn’t. They do. Facts don’t care about your feelings. There is a softer bridging argument to be made here too, to the effect that stablecoins warm up their users to the concept of digital bearer (ish) assets, even though these particular assets are significantly scammier than Bitcoin. Again, I am just floating this, not telling the reader they should or shouldn’t buy into it.

All that said, there is one argument I do want to put my own weight behind, rather than just float: stablecoin issuance is a speculative attack on the institution of fractional reserve banking. A “dollar” Alice moves from JPMorgan to Tether embodies two trade-offs from Alice’s perspective: i) a somewhat opaque profile on the credit risk of the asset: the likelihood of JPMorgan ever really defaulting on deposits vs the operator risk of Tether losing full backing and/or being wrench attacked by the Federal Government and rugging its users. These risks are real but are almost entirely political. I’m skeptical it is meaningful to quantify them, but even if it is, I am not the person to try to do it. Also, more transparently to Alice, ii) far superior payment rails (for now, more on this to follow).

However, from the perspective of the fiat banking cartel, fractional reserve leverage has been squeezed. There are just as many notional dollars in circulation, but there the backing has been shifted from levered to unlevered issuers. There are gradations of relevant objections to this: while one might say, Tether’s backing comes from Treasuries, so you are directly funding US debt issuance!, this is a bit silly in the context of what other dollars one might hold. It’s not like JPMorgan is really competing with the Treasury to sell credit into the open market. Optically they are, but this is the core of the fiat scam. Via the guarantees of the Federal Reserve System, JPMorgan can sell as much unbacked credit as it wants knowing full well the difference will be printed whenever this blows up. Short-term Treasuries are also JPMorgan’s most pristine asset safeguarding its equity, so the only real difference is that Tether only holds Treasuries without wishing more leverage into existence. The realization this all builds up to is that, by necessity,

Tether is a fully reserved bank issuing fiduciary media against the only dollar-denominated asset in existence whose value (in dollar terms) can be guaranteed. Furthermore, this media arguably has superior “moneyness” to the obvious competition in the form of US commercial bank deposits by virtue of its payment rails.

That sounds pretty great when you put it that way! Of course, the second sentence immediately leads to the second objection, and lets the argument start to pick up steam …

Objection 2: You Don’t Need a Blockchain

I don’t need to explain this to this audience but to recap as briefly as I can manage: Bitcoin’s value is entirely endogenous. Every aspect of “a blockchain” that, out of context, would be an insanely inefficient or redundant modification of a “database”, in context is geared towards the sole end of enabling the stability of this endogenous value. Historically, there have been two variations of stupidity that follow a failure to grok this: i) “utility tokens”, or blockchains with native tokens for something other than money. I would recommend anybody wanting a deeper dive on the inherent nonsense of a utility token to read Only The Strong Survive, in particular Chapter 2, Crypto Is Not Decentralized, and the subsection, Everything Fights For Liquidity, and/or Green Eggs And Ham, in particular Part II, Decentralized Finance, Technically. ii) “real world assets” or, creating tokens within a blockchain’s data structure that are not intended to have endogenous value but to act as digital quasi-bearer certificates to some or other asset of value exogenous to this system. Stablecoins are in this second category.

RWA tokens definitionally have to have issuers, meaning some entity that, in the real world, custodies or physically manages both the asset and the record-keeping scheme for the asset. “The blockchain” is at best a secondary ledger to outsource ledger updates to public infrastructure such that the issuer itself doesn’t need to bother and can just “check the ledger” whenever operationally relevant. But clearly ownership cannot be enforced in an analogous way to Bitcoin, under both technical and social considerations. Technically, Bitcoin’s endogenous value means that whoever holds the keys to some or other UTXOs functionally is the owner. Somebody else claiming to be the owner is yelling at clouds. Whereas, socially, RWA issuers enter a contract with holders (whether legally or just in terms of a common-sense interpretation of the transaction) such that ownership of the asset issued against is entirely open to dispute. That somebody can point to “ownership” of the token may or may not mean anything substantive with respect to the physical reality of control of the asset, and how the issuer feels about it all.

And so, one wonders, why use a blockchain at all? Why doesn’t the issuer just run its own database (for the sake of argument with some or other signature scheme for verifying and auditing transactions) given it has the final say over issuance and redemption anyway? I hinted at an answer above: issuing on a blockchain outsources this task to public infrastructure. This is where things get interesting. While it is technically true, given the above few paragraphs, that, you don’t need a blockchain for that, you also don’t need to not use a blockchain for that. If you want to, you can.

This is clearly the case given stablecoins exist at all and have gone this route. If one gets too angry about not needing a blockchain for that, one equally risks yelling at clouds! And, in fact, one can make an even stronger argument, more so from the end users’ perspective. These products do not exist in a vacuum but rather compete with alternatives. In the case of stablecoins, the alternative is traditional fiat money, which, as stupid as RWAs on a blockchain are, is even dumber. It actually is just a database, except it’s a database that is extremely annoying to use, basically for political reasons because the industry managing these private databases form a cartel that never needs to innovate or really give a shit about its customers at all. In many, many cases, stablecoins on blockchains are dumb in the abstract, but superior to the alternative methods of holding and transacting in dollars existing in other forms. And note, this is only from Alice’s perspective of wanting to send and receive, not a rehashing of the fractional reserve argument given above. This is the essence of their product-market-fit. Yell at clouds all you like: they just are useful given the alternative usually is not Bitcoin, it’s JPMorgan’s KYC’d-up-the-wazoo 90s-era website, more than likely from an even less solvent bank.

So where does this get us? It might seem like we are back to “product-market-fit, sorry about that” with Bitcoiners yelling about feelings while everybody else makes do with their facts. However, I think we have introduced enough material to move the argument forward by incrementally incorporating the following observations, all of which I will shortly go into in more detail: i) as a consequence of making no technical sense with respect to what blockchains are for, today’s approach won’t scale; ii) as a consequence of short-termist tradeoffs around socializing costs, today’s approach creates an extremely unhealthy and arguably unnatural market dynamic in the issuer space; iii) Taproot Assets now exist and handily address both points i) and ii), and; iv) eCash is making strides that I believe will eventually replace even Taproot Assets.

To tease where all this is going, and to get the reader excited before we dive into much more detail: just as Bitcoin will eat all monetary premia, Lightning will likely eat all settlement, meaning all payments will gravitate towards routing over Lightning regardless of the denomination of the currency at the edges. Fiat payments will gravitate to stablecoins to take advantage of this; stablecoins will gravitate to TA and then to eCash, and all of this will accelerate hyperbitcoinization by “bitcoinizing” payment rails such that an eventual full transition becomes as simple as flicking a switch as to what denomination you want to receive.

I will make two important caveats before diving in that are more easily understood in light of having laid this groundwork: I am open to the idea that it won’t be just Lightning or just Taproot Assets playing the above roles. Without veering into forecasting the entire future development of Bitcoin tech, I will highlight that all that really matters here are, respectively: a true layer 2 with native hashlocks, and a token issuance scheme that enables atomic routing over such a layer 2 (or combination of such). For the sake of argument, the reader is welcome to swap in “Ark” and “RGB” for “Lightning” and “TA” both above and in all that follows. As far as I can tell, this makes no difference to the argument and is even exciting in its own right. However, for the sake of simplicity in presentation, I will stick to “Lightning” and “TA” hereafter.

1) Today’s Approach to Stablecoins Won’t Scale

This is the easiest to tick off and again doesn’t require much explanation to this audience. Blockchains fundamentally don’t scale, which is why Bitcoin’s UTXO scheme is a far better design than ex-Bitcoin Crypto’s’ account-based models, even entirely out of context of all the above criticisms. This is because Bitcoin transactions can be batched across time and across users with combinations of modes of spending restrictions that provide strong economic guarantees of correct eventual net settlement, if not perpetual deferral. One could argue this is a decent (if abstrusely technical) definition of “scaling” that is almost entirely lacking in Crypto.

What we see in ex-Bitcoin crypto is so-called “layer 2s” that are nothing of the sort, forcing stablecoin schemes in these environments into one of two equally poor design choices if usage is ever to increase: fees go higher and higher, to the point of economic unviability (and well past it) as blocks fill up, or move to much more centralized environments that increasingly are just databases, and hence which lose the benefits of openness thought to be gleaned by outsourcing settlement to public infrastructure. This could be in the form of punting issuance to a bullshit “layer 2” that is a really a multisig “backing” a private execution environment (to be decentralized any daw now) or an entirely different blockchain that is just pretending even less not to be a database to begin with. In a nutshell, this is a decent bottom-up explanation as to why Tron has the highest settlement of Tether.

This also gives rise to the weirdness of “gas tokens” - assets whose utility as money is and only is in the form of a transaction fee to transact a different kind of money. These are not quite as stupid as a “utility token,” given at least they are clearly fulfilling a monetary role and hence their artificial scarcity can be justified. But they are frustrating from Bitcoiners’ and users’ perspectives alike: users would prefer to pay transaction fees on dollars in dollars, but they can’t because the value of Ether, Sol, Tron, or whatever, is the string and bubblegum that hold their boondoggles together. And Bitcoiners wish this stuff would just go away and stop distracting people, whereas this string and bubblegum is proving transiently useful.

All in all, today’s approach is fine so long as it isn’t being used much. It has product-market fit, sure, but in the unenviable circumstance that, if it really starts to take off, it will break, and even the original users will find it unusable.

2) Today’s Approach to Stablecoins Creates an Untenable Market Dynamic

Reviving the ethos of you don’t need a blockchain for that, notice the following subtlety: while the tokens representing stablecoins have value to users, that value is not native to the blockchain on which they are issued. Tether can (and routinely does) burn tokens on Ethereum and mint them on Tron, then burn on Tron and mint on Solana, and so on. So-called blockchains “go down” and nobody really cares. This makes no difference whatsoever to Tether’s own accounting, and arguably a positive difference to users given these actions track market demand. But it is detrimental to the blockchain being switched away from by stripping it of “TVL” that, it turns out, was only using it as rails: entirely exogenous value that leaves as quickly as it arrived.

One underdiscussed and underappreciated implication of the fact that no value is natively running through the blockchain itself is that, in the current scheme, both the sender and receiver of a stablecoin have to trust the same issuer. This creates an extremely powerful network effect that, in theory, makes the first-to-market likely to dominate and in practice has played out exactly as this theory would suggest: Tether has roughly 80% of the issuance, while roughly 19% goes to the political carve-out of USDC that wouldn’t exist at all were it not for government interference. Everybody else combined makes up the final 1%.

So, Tether is a full reserve bank but also has to be everybody’s bank. This is the source of a lot of the discomfort with Tether, and which feeds into the original objection around dollar hegemony, that there is an ill-defined but nonetheless uneasy feeling that Tether is slowly morphing into a CBDC. I would argue this really has nothing to do with Tether’s own behavior but rather is a consequence of the market dynamic inevitably created by the current stablecoin scheme. There is no reason to trust any other bank because nobody really wants a bank, they just want the rails. They want something that will retain a nominal dollar value long enough to spend it again. They don’t care what tech it runs on and they don’t even really care about the issuer except insofar as having some sense they won’t get rugged.

Notice this is not how fiat works. Banks can, of course, settle between each other, thus enabling their users to send money to customers of other banks. This settlement function is actually the entire point of central banks, less the money printing and general corruption enabled (we might say, this was the historical point of central banks, which have since become irredeemably corrupted by this power). This process is clunkier than stablecoins, as covered above, but the very possibility of settlement means there is no gigantic network effect to being the first commercial issuer of dollar balances. If it isn’t too triggering to this audience, one might suggest that the money printer also removes the residual concern that your balances might get rugged! (or, we might again say, you guarantee you don’t get rugged in the short term by guaranteeing you do get rugged in the long term).

This is a good point at which to introduce the unsettling observation that broader fintech is catching on to the benefits of stablecoins without any awareness whatsoever of all the limitations I am outlining here. With the likes of Stripe, Wise, Robinhood, and, post-Trump, even many US megabanks supposedly contemplating issuing stablecoins (obviously within the current scheme, not the scheme I am building up to proposing), we are forced to boggle our minds considering how on earth settlement is going to work. Are they going to settle through Ether? Well, no, because i) Ether isn’t money, it’s … to be honest, I don’t think anybody really knows what it is supposed to be, or if they once did they aren’t pretending anymore, but anyway, Stripe certainly hasn’t figured that out yet so, ii) it won’t be possible to issue them on layer 1s as soon as there is any meaningful volume, meaning they will have to route through “bullshit layer 2 wrapped Ether token that is really already a kind of stablecoin for Ether.”

The way they are going to try to fix this (anybody wanna bet?) is routing through DEXes, which is so painfully dumb you should be laughing and, if you aren’t, I would humbly suggest you don’t get just how dumb it is. What this amounts to is plugging the gap of Ether’s lack of moneyness (and wrapped Ether’s hilarious lack of moneyness) with … drum roll … unknowable technical and counterparty risk and unpredictable cost on top of reverting to just being a database. So, in other words, all of the costs of using a blockchain when you don’t strictly need to, and none of the benefits. Stripe is going to waste billions of dollars getting sandwich attacked out of some utterly vanilla FX settlement it is facilitating for clients who have even less of an idea what is going on and why North Korea now has all their money, and will eventually realize they should have skipped their shitcoin phase and gone straight to understanding Bitcoin instead …

3) Bitcoin (and Taproot Assets) Fixes This

To tie together a few loose ends, I only threw in the hilariously stupid suggestion of settling through wrapped Ether on Ether on Ether in order to tee up the entirely sensible suggestion of settling through Lightning. Again, not that this will be new to this audience, but while issuance schemes have been around on Bitcoin for a long time, the breakthrough of Taproot Assets is essentially the ability to atomically route through Lightning.

I will admit upfront that this presents a massive bootstrapping challenge relative to the ex-Bitcoin Crypto approach, and it’s not obvious to me if or how this will be overcome. I include this caveat to make it clear I am not suggesting this is a given. It may not be, it’s just beyond the scope of this post (or frankly my ability) to predict. This is a problem for Lightning Labs, Tether, and whoever else decides to step up to issue. But even highlighting this as an obvious and major concern invites us to consider an intriguing contrast: scaling TA stablecoins is hardest at the start and gets easier and easier thereafter. The more edge liquidity there is in TA stables, the less of a risk it is for incremental issuance; the more TA activity, the more attractive deploying liquidity is into Lightning proper, and vice versa. With apologies if this metaphor is even more confusing than it is helpful, one might conceive of the situation as being that there is massive inertia to bootstrap, but equally there could be positive feedback in driving the inertia to scale. Again, I have no idea, and it hasn’t happened yet in practice, but in theory it’s fun.

More importantly to this conversation, however, this is almost exactly the opposite dynamic to the current scheme on other blockchains, which is basically free to start, but gets more and more expensive the more people try to use it. One might say it antiscales (I don’t think that’s a real word, but if Taleb can do it, then I can do it too!).

Furthermore, the entire concept of “settling in Bitcoin” makes perfect sense both economically and technically: economically because Bitcoin is money, and technically because it can be locked in an HTLC and hence can enable atomic routing (i.e. because Lightning is a thing). This is clearly better than wrapped Eth on Eth on Eth or whatever, but, tantalisingly, is better than fiat too! The core message of the payments tome I may or may not one day write is (or will be) that fiat payments, while superficially efficient on the basis of centralized and hence costless ledger amendments, actually have a hidden cost in the form of interbank credit. Many readers will likely have heard me say this multiple times and in multiple settings but, contrary to popular belief, there is no such thing as a fiat debit. Even if styled as a debit, all fiat payments are credits and all have credit risk baked into their cost, even if that is obscured and pushed to the absolute foundational level of money printing to keep banks solvent and hence keep payment channels open.

Furthermore! this enables us to strip away the untenable market dynamic from the point above. The underappreciated and underdiscussed flip side of the drawback of the current dynamic that is effectively fixed by Taproot Assets is that there is no longer a mammoth network effect to a single issuer. Senders and receivers can trust different issuers (i.e. their own banks) because those banks can atomically settle a single payment over Lightning. This does not involve credit. It is arguably the only true debit in the world across both the relevant economic and technical criteria: it routes through money with no innate credit risk, and it does so atomically due to that money’s native properties.

Savvy readers may have picked up on a seed I planted a while back and which can now delightfully blossom:

This is what Visa was supposed to be!

Crucially, this is not what Visa is now. Visa today is pretty much the bank that is everybody’s counterparty, takes a small credit risk for the privilege, and oozes free cash flow bottlenecking global consumer payments.

But if you read both One From Many by Dee Hock (for a first person but pretty wild and extravagant take) and Electronic Value Exchange by David Stearns (for a third person, drier, but more analytical and historically contextualized take) or if you are just intimately familiar with the modern history of payments for whatever other reason, you will see that the role I just described for Lightning in an environment of unboundedly many banks issuing fiduciary media in the form of stablecoins is exactly what Dee Hock wanted to create when he envisioned Visa:

A neutral and open layer of value settlement enabling banks to create digital, interbank payment schemes for their customers at very low cost.

As it turns out, his vision was technically impossible with fiat, hence Visa, which started as a cooperative amongst member banks, was corrupted into a duopolistic for-profit rent seeker in curious parallel to the historical path of central banks …

4) eCash

To now push the argument to what I think is its inevitable conclusion, it’s worth being even more vigilant on the front of you don’t need a blockchain for that. I have argued that there is a role for a blockchain in providing a neutral settlement layer to enable true debits of stablecoins. But note this is just a fancy and/or stupid way of saying that Bitcoin is both the best money and is programmable, which we all knew anyway. The final step is realizing that, while TA is nice in terms of providing a kind of “on ramp” for global payments infrastructure as a whole to reorient around Lightning, there is some path dependence here in assuming (almost certainly correctly) that the familiarity of stablecoins as “RWA tokens on a blockchain” will be an important part of the lure.

But once that transition is complete, or is well on its way to being irreversible, we may as well come full circle and cut out tokens altogether. Again, you really don’t need a blockchain for that, and the residual appeal of better rails has been taken care of with the above massive detour through what I deem to be the inevitability of Lightning as a settlement layer. Just as USDT on Tron arguably has better moneyness than a JPMorgan balance, so a “stablecoin” as eCash has better moneyness than as a TA given it is cheaper, more private, and has more relevantly bearer properties (in other words, because it is cash). The technical detail that it can be hashlocked is really all you need to tie this all together. That means it can be atomically locked into a Lightning routed debit to the recipient of a different issuer (or “mint” in eCash lingo, but note this means the same thing as what we have been calling fully reserved banks). And the economic incentive is pretty compelling too because, for all their benefits, there is still a cost to TAs given they are issued onchain and they require asset-specific liquidity to route on Lightning. Once the rest of the tech is in place, why bother? Keep your Lightning connectivity and just become a mint.

What you get at that point is dramatically superior private database to JPMorgan with the dramatically superior public rails of Lightning. There is nothing left to desire from “a blockchain” besides what Bitcoin is fundamentally for in the first place: counterparty-risk-free value settlement.

And as a final point with a curious and pleasing echo to Dee Hock at Visa, Calle has made the point repeatedly that David Chaum’s vision for eCash, while deeply philosophical besides the technical details, was actually pretty much impossible to operate on fiat. From an eCash perspective, fiat stablecoins within the above infrastructure setup are a dramatic improvement on anything previously possible. But, of course, they are a slippery slope to Bitcoin regardless …

Objections Revisited

As a cherry on top, I think the objections I highlighted at the outset are now readily addressed – to the extent the reader believes what I am suggesting is more or less a technical and economic inevitability, that is. While, sure, I’m not particularly keen on giving the Treasury more avenues to sell its welfare-warfare shitcoin, on balance the likely development I’ve outlined is an enormous net positive: it’s going to sell these anyway so I prefer a strong economic incentive to steadily transition not only to Lightning as payment rails but eCash as fiduciary media, and to use “fintech” as a carrot to induce a slow motion bank run.

As alluded to above, once all this is in place, the final step to a Bitcoin standard becomes as simple as an individual’s decision to want Bitcoin instead of fiat. On reflection, this is arguably the easiest part! It's setting up all the tech that puts people off, so trojan-horsing them with “faster, cheaper payment rails” seems like a genius long-term strategy.

And as to “needing a blockchain” (or not), I hope that is entirely wrapped up at this point. The only blockchain you need is Bitcoin, but to the extent people are still confused by this (which I think will take decades more to fully unwind), we may as well lean into dazzling them with whatever innovation buzzwords and decentralization theatre they were going to fall for anyway before realizing they wanted Bitcoin all along.

Conclusion

Stablecoins are useful whether you like it or not. They are stupid in the abstract but it turns out fiat is even stupider, on inspection. But you don’t need a blockchain, and using one as decentralization theatre creates technical debt that is insurmountable in the long run. Blockchain-based stablecoins are doomed to a utility inversely proportional to their usage, and just to rub it in, their ill-conceived design practically creates a commercial dynamic that mandates there only ever be a single issuer.

Given they are useful, it seems natural that this tension is going to blow up at some point. It also seems worthwhile observing that Taproot Asset stablecoins have almost the inverse problem and opposite commercial dynamic: they will be most expensive to use at the outset but get cheaper and cheaper as their usage grows. Also, there is no incentive towards a monopoly issuer but rather towards as many as are willing to try to operate well and provide value to their users.

As such, we can expect any sizable growth in stablecoins to migrate to TA out of technical and economic necessity. Once this has happened - or possibly while it is happening but is clearly not going to stop - we may as well strip out the TA component and just use eCash because you really don’t need a blockchain for that at all. And once all the money is on eCash, deciding you want to denominate it in Bitcoin is the simplest on-ramp to hyperbitcoinization you can possibly imagine, given we’ve spent the previous decade or two rebuilding all payments tech around Lightning.

Or: Bitcoin fixes this. The End.

• Allen, #892,125

thanks to Marco Argentieri, Lyn Alden, and Calle for comments and feedback

@ 0176967e:1e6f471e

Co se nomádská rodina již 3 roky utíkající před kontrolou naučila o kontrole samotné? Co je to vlastně svoboda? Může koexistovat se strachem? S konfliktem? Zkusme na chvíli zapomenout na daně, policii a stát a pohlédnout na svobodu i mimo hranice společenských ideologií. Zkusme namísto hledání dalších odpovědí zjistit, zda se ještě někde neukrývají nové otázky. Možná to bude trochu ezo.

Karel provozuje již přes 3 roky se svou ženou, dvěmi dětmi a jedním psem minimalistický život v obytné dodávce. Na cestách spolu začali tvořit youtubový kanál "Karel od Martiny" o svobodě, nomádství, anarchii, rodičovství, drogách a dalších normálních věcech.

Nájdete ho aj na nostr.

@ dbc27e2e:b1dd0b0b

This method focuses on the amount of water in the first pour, which ultimately defines the coffee’s acidity and sweetness (more water = more acidity, less water = more sweetness). For the remainder of the brew, the water is divided into equal parts according to the strength you wish to attain.

Dose:

20g coffee (Coarse ground coffee)
300mL water (92°C / 197.6°F)
Time: 3:30

Instructions:

1. Pour 1: 0:00 > 50mL (42% of 120mL = 40% of total – less water in the ratio, targeting sweetness.)
2. Pour 2: 0:45 > 70mL (58% of 120mL = 40% of total – the top up for 40% of total.)
3. Pour 3: 1:30 > 60mL (The remaining water is 180mL / 3 pours = 60mL per pour)
4. Pour 4: 2:10 > 60mL
5. Pour 5: 2:40 > 60mL
6. Remove the V60 at 3:30

@ d34e832d:383f78d0

Raspberry Pi-based voice assistant

This Idea details the design and deployment of a Raspberry Pi-based voice assistant powered by the Google Gemini AI API. The system combines open hardware with modern AI services to create a low-cost, flexible, and educational voice assistant platform. By leveraging a Raspberry Pi, basic audio hardware, and Python-based software, developers can create a functional, customizable assistant suitable for home automation, research, or personal productivity enhancement.

---

1. Voice assistants

Voice assistants have become increasingly ubiquitous, but commercially available systems like Alexa, Siri, or Google Assistant come with significant privacy and customization limitations.
This project offers an open, local, and customizable alternative, demonstrating how to build a voice assistant using Google Gemini (or OpenAI’s ChatGPT) APIs for natural language understanding.

Target Audience:
- DIY enthusiasts - Raspberry Pi hobbyists - AI developers - Privacy-conscious users

---

2. System Architecture

2.1 Hardware Components

| Component | Purpose | |:--------------------------|:----------------------------------------| | Raspberry Pi (any recent model, 4B recommended) | Core processing unit | | Micro SD Card (32GB+) | Operating System and storage | | USB Microphone | Capturing user voice input | | Audio Amplifier + Speaker | Outputting synthesized responses | | 5V DC Power Supplies (2x) | Separate power for Pi and amplifier | | LEDs + Resistors (optional)| Visual feedback (e.g., recording or listening states) |

2.2 Software Stack

| Software | Function | |:---------------------------|:----------------------------------------| | Raspberry Pi OS (Lite or Full) | Base operating system | | Python 3.9+ | Programming language | | SpeechRecognition | Captures and transcribes user voice | | Google Text-to-Speech (gTTS) | Converts responses into spoken audio | | Google Gemini API (or OpenAI API) | Powers the AI assistant brain | | Pygame | Audio playback for responses | | WinSCP + Windows Terminal | File transfer and remote management |

---

3. Hardware Setup

3.1 Basic Connections

• Microphone: Connect via USB port.
• Speaker and Amplifier: Wire from Raspberry Pi audio jack or via USB sound card if better quality is needed.
• LEDs (Optional): Connect through GPIO pins, using 220–330Ω resistors to limit current.

3.2 Breadboard Layout (Optional for LEDs)

| GPIO Pin | LED Color | Purpose | |:---------|:-----------|:--------------------| | GPIO 17 | Red | Recording active | | GPIO 27 | Green | Response playing |

Tip: Use a small breadboard for quick prototyping before moving to a custom PCB if desired.

---

4. Software Setup

4.1 Raspberry Pi OS Installation

• Use Raspberry Pi Imager to flash Raspberry Pi OS onto the Micro SD card.
• Initial system update: bash sudo apt update && sudo apt upgrade -y

4.2 Python Environment

• Install Python virtual environment: bash sudo apt install python3-venv python3 -m venv voice-env source voice-env/bin/activate

• Install required Python packages: bash pip install SpeechRecognition google-generativeai pygame gtts

(Replace google-generativeai with openai if using OpenAI's ChatGPT.)

4.3 API Key Setup

• Obtain a Google Gemini API key (or OpenAI API key).
• Store safely in a .env file or configure as environment variables for security: bash export GEMINI_API_KEY="your_api_key_here"

4.4 File Transfer

• Use WinSCP or scp commands to transfer Python scripts to the Pi.

4.5 Example Python Script (Simplified)

```python import speech_recognition as sr import google.generativeai as genai from gtts import gTTS import pygame import os

genai.configure(api_key=os.getenv('GEMINI_API_KEY')) recognizer = sr.Recognizer() mic = sr.Microphone()

pygame.init()

while True: with mic as source: print("Listening...") audio = recognizer.listen(source)

try:
    text = recognizer.recognize_google(audio)
    print(f"You said: {text}")

    response = genai.generate_content(text)
    tts = gTTS(text=response.text, lang='en')
    tts.save("response.mp3")

    pygame.mixer.music.load("response.mp3")
    pygame.mixer.music.play()
    while pygame.mixer.music.get_busy():
        continue

except Exception as e:
    print(f"Error: {e}")

```

---

5. Testing and Execution

• Activate the Python virtual environment: bash source voice-env/bin/activate
• Run your main assistant script: bash python3 assistant.py
• Speak into the microphone and listen for the AI-generated spoken response.

---

6. Troubleshooting

| Problem | Possible Fix | |:--------|:-------------| | Microphone not detected | Check arecord -l | | Audio output issues | Check aplay -l, use a USB DAC if needed | | Permission denied errors | Verify group permissions (audio, gpio) | | API Key Errors | Check environment variable and internet access |

---

7. Performance Notes

• Latency: Highly dependent on network speed and API response time.
• Audio Quality: Can be enhanced with a better USB microphone and powered speakers.
• Privacy: Minimal data retention if using your own Gemini or OpenAI account.

---

8. Potential Extensions

• Add hotword detection ("Hey Gemini") using Snowboy or Porcupine libraries.
• Build a local fallback model to answer basic questions offline.
• Integrate with home automation via MQTT, Home Assistant, or Node-RED.
• Enable LED animations to visually indicate listening and responding states.
• Deploy with a small eInk or OLED screen for text display of answers.

---

9. Consider

Building a Gemini-powered voice assistant on the Raspberry Pi empowers individuals to create customizable, private, and cost-effective alternatives to commercial voice assistants. By utilizing accessible hardware, modern open-source libraries, and powerful AI APIs, this project blends education, experimentation, and privacy-centric design into a single hands-on platform.

This guide can be adapted for personal use, educational programs, or even as a starting point for more advanced AI-based embedded systems.

---

References

• Raspberry Pi Foundation: https://www.raspberrypi.org
• Google Generative AI Documentation: https://ai.google.dev
• OpenAI Documentation: https://platform.openai.com
• SpeechRecognition Library: https://pypi.org/project/SpeechRecognition/
• gTTS Documentation: https://pypi.org/project/gTTS/
• Pygame Documentation: https://www.pygame.org/docs/

@ 0176967e:1e6f471e

Lístky na festival Lunarpunku sú už v predaji na našom crowdfunding portáli. V predaji sú dva typy lístkov - štandardný vstup a špeciálny vstup spolu s workshopom oranžového leta.

Neváhajte a zabezpečte si lístok, čím skôr to urobíte, tým bude festival lepší.

Platiť môžete Bitcoinom - Lightningom aj on-chain. Vaša vstupenka je e-mail adresa (neposielame potvrdzujúce e-maily, ak platba prešla, ste in).

Kúpte si lístok

@ c631e267:c2b78d3e

Zwei mal drei macht vier, \ widewidewitt und drei macht neune, \ ich mach mir die Welt, \ widewide wie sie mir gefällt. \ Pippi Langstrumpf

Egal, ob Koalitionsverhandlungen oder politischer Alltag: Die Kontroversen zwischen theoretisch verschiedenen Parteien verschwinden, wenn es um den Kampf gegen politische Gegner mit Rückenwind geht. Wer den Alteingesessenen die Pfründe ernsthaft streitig machen könnte, gegen den werden nicht nur «Brandmauern» errichtet, sondern der wird notfalls auch strafrechtlich verfolgt. Doppelstandards sind dabei selbstverständlich inklusive.

In Frankreich ist diese Woche Marine Le Pen wegen der Veruntreuung von EU-Geldern von einem Gericht verurteilt worden. Als Teil der Strafe wurde sie für fünf Jahre vom passiven Wahlrecht ausgeschlossen. Obwohl das Urteil nicht rechtskräftig ist – Le Pen kann in Berufung gehen –, haben die Richter das Verbot, bei Wahlen anzutreten, mit sofortiger Wirkung verhängt. Die Vorsitzende des rechtsnationalen Rassemblement National (RN) galt als aussichtsreiche Kandidatin für die Präsidentschaftswahl 2027.

Das ist in diesem Jahr bereits der zweite gravierende Fall von Wahlbeeinflussung durch die Justiz in einem EU-Staat. In Rumänien hatte Călin Georgescu im November die erste Runde der Präsidentenwahl überraschend gewonnen. Das Ergebnis wurde später annulliert, die behauptete «russische Wahlmanipulation» konnte jedoch nicht bewiesen werden. Die Kandidatur für die Wahlwiederholung im Mai wurde Georgescu kürzlich durch das Verfassungsgericht untersagt.

Die Veruntreuung öffentlicher Gelder muss untersucht und geahndet werden, das steht außer Frage. Diese Anforderung darf nicht selektiv angewendet werden. Hingegen mussten wir in der Vergangenheit bei ungleich schwerwiegenderen Fällen von (mutmaßlichem) Missbrauch ganz andere Vorgehensweisen erleben, etwa im Fall der heutigen EZB-Chefin Christine Lagarde oder im «Pfizergate»-Skandal um die Präsidentin der EU-Kommission Ursula von der Leyen.

Wenngleich derartige Angelegenheiten formal auf einer rechtsstaatlichen Grundlage beruhen mögen, so bleibt ein bitterer Beigeschmack. Es stellt sich die Frage, ob und inwieweit die Justiz politisch instrumentalisiert wird. Dies ist umso interessanter, als die Gewaltenteilung einen essenziellen Teil jeder demokratischen Ordnung darstellt, während die Bekämpfung des politischen Gegners mit juristischen Mitteln gerade bei den am lautesten rufenden Verteidigern «unserer Demokratie» populär zu sein scheint.

Die Delegationen von CDU/CSU und SPD haben bei ihren Verhandlungen über eine Regierungskoalition genau solche Maßnahmen diskutiert. «Im Namen der Wahrheit und der Demokratie» möchte man noch härter gegen «Desinformation» vorgehen und dafür zum Beispiel den Digital Services Act der EU erweitern. Auch soll der Tatbestand der Volksverhetzung verschärft werden – und im Entzug des passiven Wahlrechts münden können. Auf europäischer Ebene würde Friedrich Merz wohl gerne Ungarn das Stimmrecht entziehen.

Der Pegel an Unzufriedenheit und Frustration wächst in großen Teilen der Bevölkerung kontinuierlich. Arroganz, Machtmissbrauch und immer abstrusere Ausreden für offensichtlich willkürliche Maßnahmen werden kaum verhindern, dass den etablierten Parteien die Unterstützung entschwindet. In Deutschland sind die Umfrageergebnisse der AfD ein guter Gradmesser dafür.

[Vorlage Titelbild: Pixabay]

---

Dieser Beitrag wurde mit dem Pareto-Client geschrieben und ist zuerst auf Transition News erschienen.

@ 7bdef7be:784a5805

We value sovereignty, privacy and security when accessing online content, using several tools to achieve this, like open protocols, open OSes, open software products, Tor and VPNs.

The problem

Talking about our social presence, we can manually build up our follower list (social graph), pick a Nostr client that is respectful of our preferences on what to show and how, but with the standard following mechanism, our main feed is public, so everyone can actually snoop what we are interested in, and what is supposable that we read daily.

The solution

Nostr has a simple solution for this necessity: encrypted lists. Lists are what they appear, a collection of people or interests (but they can also group much other stuff, see NIP-51). So we can create lists with contacts that we don't have in our main social graph; these lists can be used primarily to create dedicated feeds, but they could have other uses, for example, related to monitoring. The interesting thing about lists is that they can also be encrypted, so unlike the basic following list, which is always public, we can hide the lists' content from others. The implications are obvious: we can not only have a more organized way to browse content, but it is also really private one.

One might wonder what use can really be made of private lists; here are some examples:

• Browse “can't miss” content from users I consider a priority;
• Supervise competitors or adversarial parts;
• Monitor sensible topics (tags);
• Following someone without being publicly associated with them, as this may be undesirable;

The benefits in terms of privacy as usual are not only related to the casual, or programmatic, observer, but are also evident when we think of how many bots scan our actions to profile us.

The current state

Unfortunately, lists are not widely supported by Nostr clients, and encrypted support is a rarity. Often the excuse to not implement them is that they are harder to develop, since they require managing the encryption stuff (NIP-44). Nevertheless, developers have an easier option to start offering private lists: give the user the possibility to simply mark them as local-only, and never push them to the relays. Even if the user misses the sync feature, this is sufficient to create a private environment.

To date, as far as I know, the best client with list management is Gossip, which permits to manage both encrypted and local-only lists.

Beg your Nostr client to implement private lists!

@ d34e832d:383f78d0

Gist

This Idea presents a blueprint for creating a portable, offline-first education server focused on Free and Open Source Software (FOSS) topics like Bitcoin fundamentals, Linux administration, GPG encryption, and digital self-sovereignty. Using the compact and powerful Nookbox G9 NAS unit, we demonstrate how to deliver accessible, decentralized educational content in remote or network-restricted environments.

---

1. Bitcoin, Linux, and Cryptographic tools

Access to self-sovereign technologies such as Bitcoin, Linux, and cryptographic tools is critical for empowering individuals and communities. However, many areas face internet connectivity issues or political restrictions limiting access to online resources.

By combining a high-performance mini NAS server with a curated library of FOSS educational materials, we can create a mobile "university" that delivers critical knowledge independently of centralized networks.

---

2. Hardware Platform: Nookbox G9 Overview

The Nookbox G9 offers an ideal balance of performance, portability, and affordability for this project.

2.1 Core Specifications

| Feature | Specification | |:------------------------|:---------------------------------------| | Form Factor | 1U Rackmount mini-NAS | | Storage | Up to 8TB (4×2TB M.2 NVMe SSDs) | | M.2 Interface | PCIe Gen 3x2 per drive slot | | Networking | Dual 2.5 Gigabit Ethernet ports | | Power Consumption | 11–30 Watts (typical usage) | | Default OS | Windows 11 (to be replaced with Linux) | | Linux Compatibility | Fully compatible with Ubuntu 24.10 |

---

3. FOSS Education Server Design

3.1 Operating System Setup

• Replace Windows 11 with a clean install of Ubuntu Server 24.10.
• Harden the OS:
• Enable full-disk encryption.
• Configure UFW firewall.
• Disable unnecessary services.

3.2 Core Services Deployed

| Service | Purpose | |:--------------------|:-----------------------------------------| | Nginx Web Server | Host offline courses and documentation | | Nextcloud (optional) | Offer private file sharing for students | | Moodle LMS (optional) | Deliver structured courses and quizzes | | Tor Hidden Service | Optional for anonymous access locally | | rsync/Syncthing | Distribute updates peer-to-peer |

---

3.3 Content Hosted

• Bitcoin: Bitcoin Whitepaper, Bitcoin Core documentation, Electrum Wallet tutorials.
• Linux: Introduction to Linux (LPIC-1 materials), bash scripting guides, system administration manuals.
• Cryptography: GPG tutorials, SSL/TLS basics, secure communications handbooks.
• Offline Tools: Full mirrors of sites like LearnLinux.tv, Bitcoin.org, and selected content from FSF.

All resources are curated to be license-compliant and redistributable in an offline format.

---

4. Network Configuration

• LAN-only Access: No reliance on external Internet.
• DHCP server setup for automatic IP allocation.
• Optional Wi-Fi access point using USB Wi-Fi dongle and hostapd.
• Access Portal: Homepage automatically redirects users to educational content upon connection.

---

5. Advantages of This Setup

| Feature | Advantage | |:-----------------------|:----------------------------------------| | Offline Capability | Operates without internet connectivity | | Portable Form Factor | Fits into field deployments easily | | Secure and Hardened | Encrypted, compartmentalized, and locked down | | Modular Content | Easy to update or expand educational resources | | Energy Efficient | Low power draw enables solar or battery operation | | Open Source Stack | End-to-end FOSS ecosystem, no vendor lock-in |

---

6. Deployment Scenarios

• Rural Schools: Provide Linux training without requiring internet.
• Disaster Recovery Zones: Deliver essential technical education in post-disaster areas.
• Bitcoin Meetups: Offer Bitcoin literacy and cryptography workshops in remote communities.
• Privacy Advocacy Groups: Teach operational security practices without risking network surveillance.

---

7. Performance Considerations

Despite PCIe Gen 3x2 limitations, the available bandwidth (~2GB/s theoretical) vastly exceeds the server's 2.5 Gbps network output (~250MB/s), making it more than sufficient for a read-heavy educational workload.

Thermal Management:
Given the G9’s known cooling issues, install additional thermal pads or heatsinks on the NVMe drives. Consider external USB-powered cooling fans for sustained heavy usage.

---

8. Ways To Extend

• Multi-language Support: Add localized course materials.
• Bitcoin Node Integration: Host a lightweight Bitcoin node (e.g., Bitcoin Core with pruning enabled or a complete full node) for educational purposes.
• Mesh Networking: Use Mesh Wi-Fi protocols (e.g., cjdns or Yggdrasil) to allow peer-to-peer server sharing without centralized Wi-Fi.

---

9. Consider

Building a Portable FOSS Education Server on a Nookbox G9 is a practical, scalable solution for democratizing technical knowledge, empowering communities, and defending digital sovereignty in restricted environments.

Through thoughtful system design—leveraging open-source software and secure deployment practices—we enable resilient, censorship-resistant education wherever it's needed.

---

📎 References

• Ubuntu Server
• Moodle LMS
• LearnLinux.tv
• Bitcoin.org
• Tor Project

@ ecda4328:1278f072

When designing a highly available Kubernetes (or k3s) cluster, one of the key architectural questions is: "How many ETCD nodes should I run?"

A recent discussion in our team sparked this very debate. Someone suggested increasing our ETCD cluster size from 3 to more nodes, citing concerns about node failures and the need for higher fault tolerance. It’s a fair concern—nobody wants a critical service to go down—but here's why 3-node ETCD clusters are usually the sweet spot for most setups.

---

The Role of ETCD and Quorum

ETCD is a distributed key-value store used by Kubernetes to store all its state. Like most consensus-based systems (e.g., Raft), ETCD relies on quorum to operate. This means that more than half of the ETCD nodes must be online and in agreement for the cluster to function correctly.

What Quorum Means in Practice

• In a 3-node ETCD cluster, quorum is 2.
• In a 5-node cluster, quorum is 3.

⚠️ So yes, 5 nodes can tolerate 2 failures vs. just 1 in a 3-node setup—but you also need more nodes online to keep the system functional. More nodes doesn't linearly increase safety.

---

Why 3 Nodes is the Ideal Baseline

Running 3 ETCD nodes hits a great balance:

• Fault tolerance: 1 node can fail without issue.
• Performance: Fewer nodes = faster consensus and lower latency.
• Simplicity: Easier to manage, upgrade, and monitor.

Even the ETCD documentation recommends 3–5 nodes total, with 5 being the upper limit before write performance and operational complexity start to degrade.

Systems like Google's Chubby—which inspired systems like ETCD and ZooKeeper—also recommend no more than 5 nodes.

---

The Myth of Catastrophic Failure

"If two of our three ETCD nodes go down, the cluster will become unusable and need deep repair!"

This is a common fear, but the reality is less dramatic:

• ETCD becomes read-only: You can't schedule or update workloads, but existing workloads continue to run.
• No deep repair needed: As long as there's no data corruption, restoring quorum just requires bringing at least one other ETCD node back online.
• Still recoverable if two nodes are permanently lost: You can re-initialize the remaining node as a new single-node ETCD cluster using --cluster-init, and rebuild from there.

---

What About Backups?

In k3s, ETCD snapshots are automatically saved by default. For example:

• Default path: /var/lib/rancher/k3s/server/db/snapshots/

You can restore these snapshots in case of failure, making ETCD even more resilient.

---

When to Consider 5 Nodes

Adding more ETCD nodes only makes sense at scale, such as:

• Running 12+ total cluster nodes
• Needing stronger fault domains for regulatory/compliance reasons

Note: ETCD typically requires low-latency communication between nodes. Distributing ETCD members across availability zones or regions is generally discouraged unless you're using specialized networking and understand the performance implications.

Even then, be cautious—you're trading some simplicity and performance for that extra failure margin.

---

TL;DR

• 3-node ETCD clusters are the best choice for most Kubernetes/k3s environments.
• 5-node clusters offer more redundancy but come with extra complexity and performance costs.
• Loss of quorum is not a disaster—it’s recoverable.
• Backups and restore paths make even worst-case recovery feasible.

And finally: if you're seeing multiple ETCD nodes go down frequently, the real problem might not be the number of nodes—but your hosting provider.

---

@ de6c63ab:d028389b

Ever wondered why Bitcoin stops at 20,999,999.9769 and not a clean 21M? It’s not a bug — it’s brilliant.

https://blossom.primal.net/8e9e6fffbca54dfb8e55071ae590e676b355803ef18b08c8cbd9521a2eb567a8.png

Of course, it's because of this mythical and seemingly magical formula. Want to hear the full story behind this? Keep reading!

The Simple Math Behind It

In reality, there’s no magic here — it’s just an ordinary summation. That big sigma symbol (Σ) tells you that. The little “i” is the summation index, starting from 0 at the bottom and going up to 32 at the top. Why 32? We’ll get there!

After the sigma, you see the expression: 210,000 × (50 ÷ 2^i). 210,000 blocks represent one halving interval, with about 144 blocks mined per day, amounting to almost exactly four years. After each interval, the block reward halves — that’s what the division by 2^i means.

Crunching the Numbers

When i = 0 (before the first halving): 210,000 × (50 ÷ 2^0) = 10,500,000

At i = 1 (after the first halving): 210,000 × (50 ÷ 2^1) = 5,250,000

At i = 2 (after the second halving): 210,000 × (50 ÷ 2^2) = 2,625,000

…

At i = 31: 210,000 × (50 ÷ 2^31) ≈ 0.00489

At i = 32: 210,000 × (50 ÷ 2^32) ≈ 0.00244

And when you sum all of that up? 20,999,999.99755528

Except… that’s not the correct total! The real final number is: 20,999,999.9769

Where the Real Magic Happens

How come?! Here’s where the real fun begins.

We just performed the summation with real (floating-point) numbers. But computers don’t like working with real numbers. They much prefer integers. That’s also one reason why a bitcoin can’t be divided infinitely — the smallest unit is one satoshi, one hundred-millionth of a bitcoin.

And that’s also why there are exactly 33 halvings (0th, 1st, 2nd, …, 31st, 32nd). After the 32nd halving, the block reward would drop below one satoshi, making further halvings meaningless.

https://blossom.primal.net/6abae5b19bc68737c5b14785f54713e7ce11dfdecbe10c64692fc8d9a90c7f34.png

The Role of Integer Math and Bit-Shifting

Because Bitcoin operates with integers (specifically satoshis), the division (reward ÷ 2^i) is actually done using integer division. More precisely, by bit-shifting to the right:

https://blossom.primal.net/3dac403390dd24df4fa8c474db62476fba814bb8c98ca663e6e3a536f4ff7d98.png

We work with 64-bit integers. Halving the value simply means shifting the bits one position to the right.

What Happens During the Halvings

Notice: during the first 9 halvings (i = 0 to i = 8), we’re just shaving off zeros. But starting with the 9th halving (i = 9), we start losing ones. Every time a “one” falls off, it means we’re losing a tiny fraction — a remainder that would have existed if we were using real numbers.

The sum of all these lost remainders is exactly the difference between the two numbers we saw above.

And that’s why the total bitcoin supply is 20,999,999.9769 — not 21 million exactly.

Did you enjoy this? Got any questions? 🔥🚀

@ 0176967e:1e6f471e

Čo nám prinášajú exotické protokoly ako Nostr, Cashu alebo Reticulum? Šifrovanie, podpisovanie, peer to peer komunikáciu, nové spôsoby šírenia a odmeňovania obsahu.

Ukážeme si kúl appky, ako sa dajú jednotlivé siete prepájať a ako spolu súvisia.

@ 0176967e:1e6f471e

Podnikanie je jazyk s "crystal clear" pravidlami. Inštrumentalisti vidia podnikanie staticky, a toto videnie prenášajú na spoločnosť. Preto nás spoločnosť vníma často negatívne. Skutoční podnikatelia sú však "komunikátori".

Jozef Martiniak je zakladateľ AUSEKON - Institute of Austrian School of Economics

@ 1f79058c:eb86e1cb

I'm currently using this bash script to publish long-form content from local Markdown files to Nostr relays.

It requires all of yq, jq, and nak to be installed.

Usage

Create a signed Nostr event and print it to the console:

bash markdown_to_nostr.sh article-filename.md

Create a Nostr event and publish it to one or more relays:

bash markdown_to_nostr.sh article-filename.md ws://localhost:7777 wss://nostr.kosmos.org

Markdown format

You can specify your metadata as YAML in a Front Matter header. Here's an example file:

```markdown

title: "Good Morning" summary: "It's a beautiful day" image: https://example.com/i/beautiful-day.jpg date: 2025-04-24T15:00:00Z tags: gm, poetry published: false

---

In the blue sky just a few specks of gray
In the evening of a beautiful day
Though last night it rained and more rain on the way
And that more rain is needed 'twould be fair to say.

— Francis Duggan ```

The metadata keys are mostly self-explanatory. Note:

• All keys except for title are optional
• date, if present, will be set as the published_at date.
• If published is set to true, it will publish a kind 30023 event, otherwise a kind 30024 (draft)
• The d tag (widely used as URL slug for the article) will be the filename without the .md extension

@ 04c915da:3dfbecc9

One of the most common criticisms leveled against nostr is the perceived lack of assurance when it comes to data storage. Critics argue that without a centralized authority guaranteeing that all data is preserved, important information will be lost. They also claim that running a relay will become prohibitively expensive. While there is truth to these concerns, they miss the mark. The genius of nostr lies in its flexibility, resilience, and the way it harnesses human incentives to ensure data availability in practice.

A nostr relay is simply a server that holds cryptographically verifiable signed data and makes it available to others. Relays are simple, flexible, open, and require no permission to run. Critics are right that operating a relay attempting to store all nostr data will be costly. What they miss is that most will not run all encompassing archive relays. Nostr does not rely on massive archive relays. Instead, anyone can run a relay and choose to store whatever subset of data they want. This keeps costs low and operations flexible, making relay operation accessible to all sorts of individuals and entities with varying use cases.

Critics are correct that there is no ironclad guarantee that every piece of data will always be available. Unlike bitcoin where data permanence is baked into the system at a steep cost, nostr does not promise that every random note or meme will be preserved forever. That said, in practice, any data perceived as valuable by someone will likely be stored and distributed by multiple entities. If something matters to someone, they will keep a signed copy.

Nostr is the Streisand Effect in protocol form. The Streisand effect is when an attempt to suppress information backfires, causing it to spread even further. With nostr, anyone can broadcast signed data, anyone can store it, and anyone can distribute it. Try to censor something important? Good luck. The moment it catches attention, it will be stored on relays across the globe, copied, and shared by those who find it worth keeping. Data deemed important will be replicated across servers by individuals acting in their own interest.

Nostr’s distributed nature ensures that the system does not rely on a single point of failure or a corporate overlord. Instead, it leans on the collective will of its users. The result is a network where costs stay manageable, participation is open to all, and valuable verifiable data is stored and distributed forever.

@ 0176967e:1e6f471e

Ako sa snažím praktizovať LunarPunk bez budovania opcionality "odchodom" do zahraničia. Nie každý je ochotný alebo schopný meniť "miesto", ako však v takom prípade minimalizovať interakciu so štátom? Nie návod, skôr postrehy z bežného života.

@ 266815e0:6cd408a5

To all existing nostr developers and new nostr developers, stop using kind 1 events... just stop whatever your doing and switch the kind to Math.round(Math.random() * 10000) trust me it will be better

What are kind 1 events

kind 1 events are defined in NIP-10 as "simple plaintext notes" or in other words social posts.

Don't trick your users

Most users are joining nostr for the social experience, and secondly to find all the cool "other stuff" apps They find friends, browse social posts, and reply to them. If a user signs into a new nostr client and it starts asking them to sign kind 1 events with blobs of JSON, they will sign it without thinking too much about it.

Then when they return to their comfy social apps they will see that they made 10+ posts with massive amounts of gibberish that they don't remember posting. then they probably will go looking for the delete button and realize there isn't one...

Even if those kind 1 posts don't contain JSON and have a nice fancy human readable syntax. they will still confuse users because they won't remember writing those social posts

What about "discoverability"

If your goal is to make your "other stuff" app visible to more users, then I would suggest using NIP-19 and NIP-89 The first allows users to embed any other event kind into social posts as nostr:nevent1 or nostr:naddr1 links, and the second allows social clients to redirect users to an app that knows how to handle that specific kind of event

So instead of saving your apps data into kind 1 events. you can pick any kind you want, then give users a "share on nostr" button that allows them to compose a social post (kind 1) with a nostr: link to your special kind of event and by extension you app

Why its a trap

Once users start using your app it becomes a lot more difficult to migrate to a new event kind or data format. This sounds obvious, but If your app is built on kind 1 events that means you will be stuck with their limitations forever.

For example, here are some of the limitations of using kind 1 - Querying for your apps data becomes much more difficult. You have to filter through all of a users kind 1 events to find which ones are created by your app - Discovering your apps data is more difficult for the same reason, you have to sift through all the social posts just to find the ones with you special tag or that contain JSON - Users get confused. as mentioned above users don't expect "other stuff" apps to be creating special social posts - Other nostr clients won't understand your data and will show it as a social post with no option for users to learn about your app

@ 0176967e:1e6f471e

Tento rok vás čaká workshop na tému "oranžové leto" s Jurajom Bednárom a Mariannou Sádeckou. Dozviete sa ako mení naše vnímanie skúsenosť s Bitcoinom, ako sa navigovať v dnešnom svete a odstrániť mentálnu hmlu spôsobenú fiat životom.

Na workshop je potrebný extra lístok (môžete si ho dokúpiť aj na mieste).

Pre viac informácií o oranžovom lete odporúčame pred workshopom vypočuťi si podcast na túto tému.

@ 16f1a010:31b1074b

grain is a nostr relay built using Go, currently utilizing MongoDB as its database. Binaries are provided for AMD64 Windows and Linux. grain is Go Relay Architecture for Implementing Nostr

Introduction

grain is a nostr relay built using Go, currently utilizing MongoDB as its database. Binaries are provided for AMD64 Windows and Linux. grain is Go Relay Architecture for Implementing Nostr

Prerequisites

• Grain requires a running MongoDB instance. Please refer to this separate guide for instructions on setting up MongoDB: nostr:naddr1qvzqqqr4gupzq9h35qgq6n8ll0xyyv8gurjzjrx9sjwp4hry6ejnlks8cqcmzp6tqqxnzde5xg6rwwp5xsuryd3knfdr7g

Download Grain

Download the latest release for your system from the GitHub releases page

amd64 binaries provided for Windows and Linux, if you have a different CPU architecture, you can download and install go to build grain from source

Installation and Execution

• Create a new folder on your system where you want to run Grain.
• The downloaded binary comes bundled with a ZIP file containing a folder named "app," which holds the frontend HTML files. Unzip the "app" folder into the same directory as the Grain executable.

Run Grain

• Open your terminal or command prompt and navigate to the Grain directory.
• Execute the Grain binary.

on linux you will first have to make the program executable

chmod +x grain_linux_amd64

Then you can run the program

./grain_linux_amd64

(alternatively on windows, you can just double click the grain_windows_amd64.exe to start the relay)

You should see a terminal window displaying the port on which your relay and frontend are running.

If you get

Failed to copy app/static/examples/config.example.yml to config.yml: open app/static/examples/config.example.yml: no such file or directory

Then you probably forgot to put the app folder in the same directory as your executable or you did not unzip the folder.

Congrats! You're running grain 🌾!

You may want to change your NIP11 relay information document (relay_metadata.json) This informs clients of the capabilities, administrative contacts, and various server attributes. It's located in the same directory as your executable.

Configuration Files

Once Grain has been executed for the first time, it will generate the default configuration files inside the directory where the executable is located. These files are:

bash config.yml whitelist.yml blacklist.yml

Prerequisites: - Grain requires a running MongoDB instance. Please refer to this separate guide for instructions on setting up MongoDB: [Link to MongoDB setup guide].

Download Grain:

Download the latest release for your system from the GitHub releases page

amd64 binaries provided for Windows and Linux, if you have a different CPU architecture, you can download and install go to build grain from source

Installation and Execution:

• Create a new folder on your system where you want to run Grain.
• The downloaded binary comes bundled with a ZIP file containing a folder named "app," which holds the frontend HTML files. Unzip the "app" folder into the same directory as the Grain executable.

Run Grain:

• Open your terminal or command prompt and navigate to the Grain directory.
• Execute the Grain binary.

on linux you will first have to make the program executable

chmod +x grain_linux_amd64

Then you can run the program

./grain_linux_amd64

(alternatively on windows, you can just double click the grain_windows_amd64.exe to start the relay)

You should see a terminal window displaying the port on which your relay and frontend are running.

If you get

Failed to copy app/static/examples/config.example.yml to config.yml: open app/static/examples/config.example.yml: no such file or directory

Then you probably forgot to put the app folder in the same directory as your executable or you did not unzip the folder.

Congrats! You're running grain 🌾!

You may want to change your NIP11 relay information document (relay_metadata.json) This informs clients of the capabilities, administrative contacts, and various server attributes. It's located in the same directory as your executable.

Configuration Files:

Once Grain has been executed for the first time, it will generate the default configuration files inside the directory where the executable is located. These files are:

bash config.yml whitelist.yml blacklist.yml

Configuration Documentation

You can always find the latest example configs on my site or in the github repo here: config.yml

whitelist.yml

blacklist.yml

Config.yml

This config.yml file is where you customize how your Grain relay operates. Each section controls different aspects of the relay's behavior.

1. mongodb (Database Settings)

• uri: mongodb://localhost:27017/:
  • This is the connection string for your MongoDB database.
  • mongodb://localhost:27017/ indicates that your MongoDB server is running on the same computer as your Grain relay (localhost) and listening on port 27017 (the default MongoDB port).
  • If your MongoDB server is on a different machine, you'll need to change localhost to the server's IP address or hostname.
  • The trailing / indicates the root of the mongodb server. You will define the database in the next line.
• database: grain:
  • This specifies the name of the MongoDB database that Grain will use to store Nostr events. Grain will create this database if it doesn't already exist.
  • You can name the database whatever you want. If you want to run multiple grain relays, you can and they can have different databases running on the same mongo server.

2. server (Relay Server Settings)

• port: :8181:
  • This sets the port on which your Grain relay will listen for incoming nostr websocket connections and what port the frontend will be available at.
• read_timeout: 10 # in seconds:
  • This is the maximum time (in seconds) that the relay will wait for a client to send data before closing the connection.
• write_timeout: 10 # in seconds:
  • This is the maximum time (in seconds) that the relay will wait for a client to receive data before closing the connection.
• idle_timeout: 120 # in seconds:
  • This is the maximum time (in seconds) that the relay will keep a connection open if there's no activity.
• max_connections: 100:
  • This sets the maximum number of simultaneous client connections that the relay will allow.
• max_subscriptions_per_client: 10:
  • This sets the maximum amount of subscriptions a single client can request from the relay.

3. resource_limits (System Resource Limits)

• cpu_cores: 2 # Limit the number of CPU cores the application can use:
  • This restricts the number of CPU cores that Grain can use. Useful for controlling resource usage on your server.
• memory_mb: 1024 # Cap the maximum amount of RAM in MB the application can use:
  • This limits the maximum amount of RAM (in megabytes) that Grain can use.
• heap_size_mb: 512 # Set a limit on the Go garbage collector's heap size in MB:
  • This sets a limit on the amount of memory that the Go programming language's garbage collector can use.

4. auth (Authentication Settings)

• enabled: false # Enable or disable AUTH handling:
  • If set to true, this enables authentication handling, requiring clients to authenticate before using the relay.
• relay_url: "wss://relay.example.com/" # Specify the relay URL:
  • If authentication is enabled, this is the url that clients will use to authenticate.

5. UserSync (User Synchronization)

• user_sync: false:
  • If set to true, the relay will attempt to sync user data from other relays.
• disable_at_startup: true:
  • If user sync is enabled, this will prevent the sync from starting when the relay starts.
• initial_sync_relays: [...]:
  • A list of other relays to pull user data from.
• kinds: []:
  • A list of event kinds to pull from the other relays. Leaving this empty will pull all event kinds.
• limit: 100:
  • The limit of events to pull from the other relays.
• exclude_non_whitelisted: true:
  • If set to true, only users on the whitelist will have their data synced.
• interval: 360:
  • The interval in minutes that the relay will resync user data.

6. backup_relay (Backup Relay)

• enabled: false:
  • If set to true, the relay will send copies of received events to the backup relay.
• url: "wss://some-relay.com":
  • The url of the backup relay.

7. event_purge (Event Purging)

• enabled: false:
  • If set to true, the relay will automatically delete old events.
• keep_interval_hours: 24:
  • The number of hours to keep events before purging them.
• purge_interval_minutes: 240:
  • How often (in minutes) the purging process runs.
• purge_by_category: ...:
  • Allows you to specify which categories of events (regular, replaceable, addressable, deprecated) to purge.
• purge_by_kind_enabled: false:
  • If set to true, events will be purged based on the kinds listed below.
• kinds_to_purge: ...:
  • A list of event kinds to purge.
• exclude_whitelisted: true:
  • If set to true, events from whitelisted users will not be purged.

8. event_time_constraints (Event Time Constraints)

• min_created_at: 1577836800:
  • The minimum created_at timestamp (Unix timestamp) that events must have to be accepted by the relay.
• max_created_at_string: now+5m:
  • The maximum created at time that an event can have. This example shows that the max created at time is 5 minutes in the future from the time the event is received.
  • min_created_at_string and max_created_at work the same way.

9. rate_limit (Rate Limiting)

• ws_limit: 100:
  • The maximum number of WebSocket messages per second that the relay will accept.
• ws_burst: 200:
  • Allows a temporary burst of WebSocket messages.
• event_limit: 50:
  • The maximum number of Nostr events per second that the relay will accept.
• event_burst: 100:
  • Allows a temporary burst of Nostr events.
• req_limit: 50:
  • The limit of http requests per second.
• req_burst: 100:
  • The allowed burst of http requests.
• max_event_size: 51200:
  • The maximum size (in bytes) of a Nostr event that the relay will accept.
• kind_size_limits: ...:
  • Allows you to set size limits for specific event kinds.
• category_limits: ...:
  • Allows you to set rate limits for different event categories (ephemeral, addressable, regular, replaceable).
• kind_limits: ...:
  • Allows you to set rate limits for specific event kinds.

By understanding these settings, you can tailor your Grain Nostr relay to meet your specific needs and resource constraints.

whitelist.yml

The whitelist.yml file is used to control which users, event kinds, and domains are allowed to interact with your Grain relay. Here's a breakdown of the settings:

1. pubkey_whitelist (Public Key Whitelist)

• enabled: false:
  • If set to true, this enables the public key whitelist. Only users whose public keys are listed will be allowed to publish events to your relay.
• pubkeys::
  • A list of hexadecimal public keys that are allowed to publish events.
  • pubkey1 and pubkey2 are placeholders, you will replace these with actual hexadecimal public keys.
• npubs::
  • A list of npubs that are allowed to publish events.
  • npub18ls2km9aklhzw9yzqgjfu0anhz2z83hkeknw7sl22ptu8kfs3rjq54am44 and npub2 are placeholders, replace them with actual npubs.
  • npubs are bech32 encoded public keys.

2. kind_whitelist (Event Kind Whitelist)

• enabled: false:
  • If set to true, this enables the event kind whitelist. Only events with the specified kinds will be allowed.
• kinds::
  • A list of event kinds (as strings) that are allowed.
  • "1" and "2" are example kinds. Replace these with the kinds you want to allow.
  • Example kinds are 0 for metadata, 1 for short text notes, and 2 for recommend server.

3. domain_whitelist (Domain Whitelist)

• enabled: false:
  • If set to true, this enables the domain whitelist. This checks the domains .well-known folder for their nostr.json. This file contains a list of pubkeys. They will be considered whitelisted if on this list.
• domains::
  • A list of domains that are allowed.
  • "example.com" and "anotherdomain.com" are example domains. Replace these with the domains you want to allow.

blacklist.yml

The blacklist.yml file allows you to block specific content, users, and words from your Grain relay. Here's a breakdown of the settings:

1. enabled: true

• This setting enables the blacklist functionality. If set to true, the relay will actively block content and users based on the rules defined in this file.

2. permanent_ban_words:

• This section lists words that, if found in an event, will result in a permanent ban for the event's author.
• - really bad word is a placeholder. Replace it with any words you want to permanently block.

3. temp_ban_words:

• This section lists words that, if found in an event, will result in a temporary ban for the event's author.
• - crypto, - web3, and - airdrop are examples. Replace them with the words you want to temporarily block.

4. max_temp_bans: 3

• This sets the maximum number of temporary bans a user can receive before they are permanently banned.

5. temp_ban_duration: 3600

• This sets the duration of a temporary ban in seconds. 3600 seconds equals one hour.

6. permanent_blacklist_pubkeys:

• This section lists hexadecimal public keys that are permanently blocked from using the relay.
• - db0c9b8acd6101adb9b281c5321f98f6eebb33c5719d230ed1870997538a9765 is an example. Replace it with the public keys you want to block.

7. permanent_blacklist_npubs:

• This section lists npubs that are permanently blocked from using the relay.
• - npub1x0r5gflnk2mn6h3c70nvnywpy2j46gzqwg6k7uw6fxswyz0md9qqnhshtn is an example. Replace it with the npubs you want to block.
• npubs are the human readable version of public keys.

8. mutelist_authors:

• This section lists hexadecimal public keys of author of a kind1000 mutelist. Pubkey authors on this mutelist will be considered on the permanent blacklist. This provides a nostr native way to handle the backlist of your relay
• - 3fe0ab6cbdb7ee27148202249e3fb3b89423c6f6cda6ef43ea5057c3d93088e4 is an example. Replace it with the public keys of authors that have a mutelist you would like to use as a blacklist. Consider using your own.
• Important Note: The mutelist Event MUST be stored in this relay for it to be retrieved. This means your relay must have a copy of the authors kind10000 mutelist to consider them for the blacklist.

Running Grain as a Service:

Windows Service:

To run Grain as a Windows service, you can use tools like NSSM (Non-Sucking Service Manager). NSSM allows you to easily install and manage any application as a Windows service.

* For instructions on how to install NSSM, please refer to this article: [Link to NSSM install guide coming soon].

1. Open Command Prompt as Administrator:

   • Open the Windows Start menu, type "cmd," right-click on "Command Prompt," and select "Run as administrator."

2. Navigate to NSSM Directory:

   • Use the cd command to navigate to the directory where you extracted NSSM. For example, if you extracted it to C:\nssm, you would type cd C:\nssm and press Enter.

3. Install the Grain Service:

   • Run the command nssm install grain.
   • A GUI will appear, allowing you to configure the service.

4. Configure Service Details:

   • In the "Path" field, enter the full path to your Grain executable (e.g., C:\grain\grain_windows_amd64.exe).
   • In the "Startup directory" field, enter the directory where your Grain executable is located (e.g., C:\grain).

5. Install the Service:

   • Click the "Install service" button.

6. Manage the Service:

   • You can now manage the Grain service using the Windows Services manager. Open the Start menu, type "services.msc," and press Enter. You can start, stop, pause, or restart the Grain service from there.

Linux Service (systemd):

To run Grain as a Linux service, you can use systemd, the standard service manager for most modern Linux distributions.

1. Create a Systemd Service File:

   • Open a text editor with root privileges (e.g., sudo nano /etc/systemd/system/grain.service).

2. Add Service Configuration:

   • Add the following content to the grain.service file, replacing the placeholders with your actual paths and user information:

   ```toml [Unit] Description=Grain Nostr Relay After=network.target

   [Service] ExecStart=/path/to/grain_linux_amd64 WorkingDirectory=/path/to/grain/directory Restart=always User=your_user #replace your_user Group=your_group #replace your_group

   [Install] WantedBy=multi-user.target ```

   • Replace /path/to/grain/executable with the full path to your Grain executable.
   • Replace /path/to/grain/directory with the directory containing your Grain executable.
   • Replace your_user and your_group with the username and group that will run the Grain service.

3. Reload Systemd:

   • Run the command sudo systemctl daemon-reload to reload the systemd configuration.

4. Enable the Service:

   • Run the command sudo systemctl enable grain.service to enable the service to start automatically on boot.

5. Start the Service:

   • Run the command sudo systemctl start grain.service to start the service immediately.

6. Check Service Status:

   • Run the command sudo systemctl status grain.service to check the status of the Grain service. This will show you if the service is running and any recent logs.
   • You can run sudo journalctl -f -u grain.service to watch the logs

More guides are in the works for setting up tailscale to access your relay from anywhere over a private network and for setting up a cloudflare tunnel to your domain to deploy a grain relay accessible on a subdomain of your site eg wss://relay.yourdomain.com

@ 3bf0c63f:aefa459d

Why relay hints are important

Recently Coracle has removed support for following relay hints in Nostr event references.

Supposedly Coracle is now relying only on public key hints and kind:10002 events to determine where to fetch events from a user. That is a catastrophic idea that destroys much of Nostr's flexibility for no gain at all.

• Someone makes a post inside a community (either a NIP-29 community or a NIP-87 community) and others want to refer to that post in discussions in the external Nostr world of kind:1s -- now that cannot work because the person who created the post doesn't have the relays specific to those communities in their outbox list;
• There is a discussion happening in a niche relay, for example, a relay that can only be accessed by the participants of a conference for the duration of that conference -- since that relay is not in anyone's public outbox list, it's impossible for anyone outside of the conference to ever refer to these events;
• Some big public relays, say, relay.damus.io, decide to nuke their databases or periodically delete old events, a user keeps using that big relay as their outbox because it is fast and reliable, but chooses to archive their old events in a dedicated archival relay, say, cellar.nostr.wine, while prudently not including that in their outbox list because that would make no sense -- now it is impossible for anyone to refer to old notes from this user even though they are publicly accessible in cellar.nostr.wine;
• There are topical relays that curate content relating to niche (non-microblogging) topics, say, cooking recipes, and users choose to publish their recipes to these relays only -- but now they can't refer to these relays in the external Nostr world of kind:1s because these topical relays are not in their outbox lists.
• Suppose a user wants to maintain two different identities under the same keypair, say, one identity only talks about soccer in English, while the other only talks about art history in French, and the user very prudently keeps two different kind:10002 events in two different sets of "indexer" relays (or does it in some better way of announcing different relay sets) -- now one of this user's audiences cannot ever see notes created by him with their other persona, one half of the content of this user will be inacessible to the other half and vice-versa.
• If for any reason a relay does not want to accept events of a certain kind a user may publish to other relays, and it would all work fine if the user referenced that externally-published event from a normal event, but now that externally-published event is not reachable because the external relay is not in the user's outbox list.
• If someone, say, Alex Jones, is hard-banned everywhere and cannot event broadcast kind:10002 events to any of the commonly used index relays, that person will now appear as banned in most clients: in an ideal world in which clients followed nprofile and other relay hints Alex Jones could still live a normal Nostr life: he would print business cards with his nprofile instead of an npub and clients would immediately know from what relay to fetch his posts. When other users shared his posts or replied to it, they would include a relay hint to his personal relay and others would be able to see and then start following him on that relay directly -- now Alex Jones's events cannot be read by anyone that doesn't already know his relay.

@ 5f078e90:b2bacaa3

Panda story 3

Initially posted on Hive, story is between 300 and 500 characters. Should become a Nostr kind 30023. Image has markdown.

In a misty bamboo forest, a red panda named Rolo discovered a glowing berry. Curious, he nibbled it and began to float! Drifting over treetops, he saw his friends below, waving. Rolo somersaulted through clouds, giggling as wind tickled his fur. The berry's magic faded at dusk, landing him softly by a stream. His pals cheered his tale, and Rolo dreamed of more adventures, his heart light as the breeze. (349 characters)

---

Originally posted on Hive at https://hive.blog/@hostr/panda-story-3

Cross-posted using Hostr, version 0.0.3

@ 266815e0:6cd408a5

NOTE: this is just a quick technical guide. sorry for the lack of details

Install NodeJS

Download it from the official website https://nodejs.org/en/download

Or use nvm https://github.com/nvm-sh/nvm?tab=readme-ov-file#install--update-script

bash wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash nvm install 20

Clone example config.yml

bash wget https://raw.githubusercontent.com/hzrd149/blossom-server/master/config.example.yml -O config.yml

Modify config.yml

```bash nano config.yml

or if your that type of person

vim config.yml ```

Run blossom-server

```bash npx blossom-server-ts

or install it locally and run using npm

npm install blossom-server-ts ./node_modules/.bin/blossom-server-ts ```

Now you can open http://localhost:3000 and see your blossom server

And if you set the dashboard.enabled option in the config.yml you can open http://localhost:3000/admin to see the admin dashboard

@ 502ab02a:a2860397

วันนี้เรามาย้อนอดีตเล็กน้อยกันครับ กับ ผลิตภัณฑ์ไขมันพืชแปรรูปแบบแรกๆของโลก ที่ใช้กระบวนการแปรรูปน้ำมันพืชด้วยเคมี (hydrogenation) เพื่อให้ได้ไขมันกึ่งแข็ง

ในเดือนมิถุนายน ค.ศ. 1911 บริษัท Procter & Gamble เปิดตัวผลิตภัณฑ์ใหม่ที่เปลี่ยนโฉมวงการทำอาหารบ้านๆ ทั่วอเมริกา ตราสินค้า “Crisco” ซึ่งมาจากคำว่า “crystallized cottonseed oil” ได้ถือกำเนิดขึ้นเป็น “vegetable shortening” หรือที่บ้านเราเรียกว่าเนยขาว ก้อนแรกที่ทำมาจากน้ำมันพืชล้วนๆ แทนที่ไขมันสัตว์อย่างเนยหรือน้ำมันหมู จัดเป็นจุดเริ่มต้นของการปฏิวัติวิธีปรุงอาหารในครัวเรือนสหรัฐฯ

ก่อนหน้านั้น คนอเมริกันคุ้นเคยกับการใช้เนย ชีส หรือน้ำมันหมูในการประกอบอาหาร แต่ Crisco มาพร้อมการโฆษณาว่า “สะอาดกว่า” และ “ประหยัดกว่า” เพราะไม่ต้องเสี่ยงกับกลิ่นคาวหรือการเน่าเสียของไขมันสัตว์ อีกทั้งบรรจุในกระป๋องสีขาวสะอาด จึงดูทันสมัยน่าต้องการ

ชื่อ “Crisco” นั้นไม่ได้ตั้งโดยบังเอิญ แต่มาจากการย่อวลี “crystallized cottonseed oil” ให้สั้นกระชับและติดหู (ต้นชื่อ “Krispo” เคยถูกทดลองก่อน แต่ติดปัญหาเครื่องหมายการค้า และชื่อ “Cryst” ก็ถูกทิ้งไปเพราะมีนัยยะทางศาสนา)

กระบวนการสำคัญคือการนำเอาน้ำมันฝ้ายเหลวไปเติมไฮโดรเจน (hydrogenation) จนแข็งตัวได้เองในอุณหภูมิห้อง ผลลัพธ์คือไขมันทรานส์ที่ช่วยให้มาการีนแข็งตัวดี

ภายในเวลาไม่นานหลังการเปิดตัว โฆษณาในหนังสือพิมพ์และวิทยุกระจายเสียงฉบับแรกของ Crisco ก็เริ่มขึ้นอย่างดุเดือด พ่วงด้วยการแจก “ตำรา Crisco” ให้แม่บ้านลองนำไปใช้ทั้งอบ ทั้งทอด จึงเกิด “ยุคครัว Crisco” อย่างแท้จริง

แม้ Crisco จะถูกยกให้เป็น “จุดเริ่มต้นของยุคไขมันพืช” ในครัวอเมริกัน แต่เบื้องหลังขวดสีเขียว–ขาวที่เติมเต็มชั้นเก็บของในบ้านกลับมีดราม่าและบทเรียนมากกว่าที่ใครคาดคิด

ย้อนกลับไปทศวรรษ 1910 เมื่อ Procter & Gamble เปิดตัว Crisco ในฐานะ “ไขมันพืชสุดสะอาด” พร้อมกับโฆษณาว่าเป็นทางเลือกที่ดีกว่าเนยและแลร์ดเดิม ๆ แต่ความท้าทายแรกคือ “ฝืนความเชื่อ” ของคุณแม่บ้านยุคนั้น ที่ยังยึดติดกับไขมันจากสัตว์ นักการตลาดของ P&G จึงสร้างภาพลักษณ์ให้ Crisco ดูเป็นผลิตภัณฑ์อุตสาหกรรมขั้นสูง โปร่งใส และถูกสุขอนามัยสู้กับค่านิยมเดิมได้อย่างน่าทึ่ง

หนังสือพิมพ์ในยุคนั้นพูดกันว่า มันคือไขมันพืชปฏิวัติวงการ ที่ทั้งถูกกว่าและยืดอายุได้ไกลกว่าน้ำมันสัตว์

กระทั่งปลายทศวรรษ 1980 เกิดดราม่าสะท้อนความย้อนแย้งในวงการสุขภาพ เมื่อองค์กร CSPI (Center for Science in the Public Interest) กลับออกมาชื่นชมการใช้ไขมันทรานส์จาก Crisco ว่า “ดีต่อหลอดเลือด” เมื่อเทียบกับไขมันอิ่มตัวจากมะพร้าว เนย หรือไขมันสัตว์

นี่คือครั้งที่วงการแพทย์และโภชนาการแตกแยกกันว่าอะไรจริงหรือหลอก จนกระทั่งงานวิจัยยืนยันชัดเจนว่าไขมันทรานส์เป็นอันตรายต่อหัวใจจริง ๆ

แต่เมื่อเวลาผ่านไป งานวิจัยคุณภาพสูงเริ่มชี้ชัดว่า ไขมันทรานส์ ไม่ใช่เพียงส่วนเกินในเมนูขนมกรอบๆ เท่านั้น มันเป็นภัยเงียบที่เพิ่มความเสี่ยงโรคหลอดเลือดหัวใจ และการอักเสบเรื้อรัง WHO จึงออกมาตรการให้โลก “เลิกทรานส์แฟต” ภายในปี 2023 ทำให้ Procter & Gamble ปรับสูตร Crisco มาใช้การผสมระหว่างน้ำมันฝ้าย fully hydrogenated กับน้ำมันเหลว ผ่านกระบวนการ interesterification แทน เพื่อให้ได้จุดหลอมเหลวที่เหมาะสมโดยไม่สร้างทรานส์แฟตเพิ่มอีก

อีกประเด็นดราม่าที่ตามมาเมื่อ Procter & Gamble ต้องปรับสูตร Crisco ให้เป็น “trans fat–free” ในปี 2004 และยุติการขายสูตรปราศจากทรานส์เฉพาะทางในปี 2007 ก่อนจะกลับมาใช้ fully hydrogenated palm oil ตามกฎ FDA ในปี 2018

แต่การหันมาใช้น้ำมันปาล์มเต็มตัวกลับก่อปัญหาใหม่ คือข้อครหาเรื่องการทำลายป่าเขตร้อนเพื่อปลูกปาล์มน้ำมัน จนกลายเป็นดราม่าระดับโลกเรื่องสิ่งแวดล้อมและสิทธิมนุษยชนในชุมชนท้องถิ่น

แด่วันนี้ เมื่อใครยังพูดถึง Crisco ด้วยสายตาเด็กน้อยที่เห็นไขมันพืชขาวโพลน เป็นคำตอบใหม่ของครัวสะอาด เราอาจยกมือทักว่า “อย่าลืมดูเบื้องหลังของมัน” เพราะไขมันที่เกิดจากการ “สลับตำแหน่งกรดไขมัน” ผ่านความร้อนสูงและสารเคมี ไม่ใช่ไขมันที่ธรรมชาติออกแบบมาให้ร่างกายคุ้นเคยจริงๆ แม้จะมีชื่อใหม่ สูตรใหม่ แต่ต้นกำเนิดของการปฏิวัติครัวในปี 1911

Crisco ไม่ได้เป็นแค่พรีเซนเตอร์ “ไขมันพืชเพื่อสุขภาพ” แต่ยังเป็นบทเรียนสำคัญเรื่องการตลาดอาหารอุตสาหกรรม การวิจัยทางโภชนาการที่ต้องพัฒนาไม่หยุดนิ่ง และผลกระทบต่อสิ่งแวดล้อมเมื่อเราหันมาใช้วัตถุดิบใหม่ๆ ดังนั้น ครัวของเราอาจจะสะอาดทันสมัย แต่ก็ต้องเลือกให้รอบคอบและติดตามเบื้องหลังของทุกขวดที่เราใช้เสมอครับ

ไหนๆก็ไหนๆแล้ว ขออธิบายคุณลักษณะของ เนยขาวไปยาวๆเลยแล้วกันนะครับ ขี้เกียจแยกโพส 55555555

เนยขาว หรือชื่อทางเทคนิคว่า “shortening” ไม่ได้มีส่วนผสมของนม หรือเนยแท้ใดๆ ทั้งสิ้น แต่มันคือไขมันพืชที่ผ่านกระบวนการทำให้แข็งตัว และคงรูปได้ดี เส้นทางของเนยขาวเริ่มด้วยการเปลี่ยนโครงสร้างไขมันไม่อิ่มตัวในน้ำมันพืชให้กลายเป็นไขมันอิ่มตัวมากขึ้น กระบวนการนี้เรียกว่า hydrogenation หรือการเติมไฮโดรเจนเข้าไปในโมเลกุลของไขมัน โดยใช้อุณหภูมิสูงและตัวเร่งปฏิกิริยาอย่าง “นิกเกิล” เพื่อให้ไขมันพืชที่เหลวกลายเป็นของแข็งที่อยู่ตัว ไม่เหม็นหืนง่าย และสามารถเก็บได้นานขึ้น

ผลพลอยได้ของการ hydrogenation คือการเกิดขึ้นของ ไขมันทรานส์ (trans fat) ซึ่งเป็นไขมันที่ร่างกายแทบไม่มีระบบจัดการ และได้รับการยืนยันจากงานวิจัยนับไม่ถ้วนว่าเป็นหนึ่งในปัจจัยเสี่ยงสำคัญต่อโรคหัวใจ หลอดเลือด และการอักเสบเรื้อรังในร่างกาย แม้ในยุคปัจจุบันบางผู้ผลิตจะเปลี่ยนวิธีการผลิตไปใช้การปรับโครงสร้างไขมันด้วยวิธี interesterification ที่ช่วยลดทรานส์แฟตลงได้มาก แต่ก็ยังคงเป็นกระบวนการแทรกแซงโครงสร้างไขมันจากธรรมชาติรวมถึงใช้กระบวนการ RBD ที่เราคุยกันไปแล้วอยู่ดี และผลกระทบต่อร่างกายในระยะยาวก็ยังเป็นคำถามที่นักโภชนาการสาย real food หลายคนตั้งข้อสังเกต

คำว่า “shortening” มาจากคำกริยา shorten ที่แปลว่า "ทำให้สั้นลง" ซึ่งในบริบทของการทำขนม มันหมายถึง การไปยับยั้งไม่ให้เส้นใยกลูเตนในแป้งพัฒนาได้ยาวและเหนียวตามธรรมชาติ เวลาผสมแป้งกับน้ำ โปรตีนในแป้งสองตัวคือกลูเตนิน (glutenin) กับไกลอาดิน (gliadin) จะจับกันกลายเป็นกลูเตน ซึ่งมีคุณสมบัติยืดหยุ่น เหนียว เหมาะกับขนมปังที่ต้องการโครงสร้างแน่นๆ ยืดๆ หนึบๆ

แต่พอเราใส่ shortening ลงไป เช่น เนยขาว น้ำมัน หรือไขมันที่อยู่ในสถานะกึ่งของแข็ง มันจะไปเคลือบเส้นแป้ง ทำให้โปรตีนกลูเตนจับกันไม่ได้เต็มที่ ผลคือเส้นใยกลูเตนถูก “ทำให้สั้นลง” แทนที่จะยืดหยุ่นยาวแบบในขนมปัง เลยกลายเป็นเนื้อขนมที่ร่วน นุ่ม ละลายในปาก หรือแม้แต่กรอบ อย่างคุกกี้ พาย หรือโรตีบางๆ หอมๆ นั่นแหละ เป็นสัมผัสที่นักทำขนมรักใคร่ แต่ร่างกายอาจไม่ปลื้มสักเท่าไหร่

เพราะจุดสังเกตุคือ เรื่องไขมันทรานส์ หลายแบรนด์ที่ขั้นตอนการผลิตไม่ดีพอ อาจพยายามเขียนฉลากว่า “ไม่มี trans fat” หรือ “low trans” แต่ในความเป็นจริงแล้ว หากไขมันทรานส์ต่ำกว่า 0.5 กรัมต่อหนึ่งหน่วยบริโภค ผู้ผลิตสามารถระบุว่าเป็น 0 ได้ตามกฎหมาย ซึ่งหากกินหลายๆ หน่วยรวมกัน ก็ไม่ต่างจากการเปิดประตูให้ trans fat ย่องเข้าร่างแบบไม่รู้ตัว

แต่เหนือกว่านั้นก็คือเรื่องเดิมๆที่เราเข้าใจกันดีในน้ำมันพืช นั่นคือ โอเมก้า 6 เพียบ + กระบวนการปรุงแต่งเคมี ที่เปราะบางต่ออุณหภูมิ ทำให้เกิดการออกซิเดชัน นำไปสู่โรคจากการอักเสบของร่างกาย

อาจถึงเวลาแล้วที่เราควรเปิดใจกลับไปหาความเรียบง่ายของไขมันจากธรรมชาติ สิ่งที่ดูสะอาด ขาว และอยู่ตัวดีเกินไป อาจไม่ใช่สิ่งที่ธรรมชาติอยากให้เข้าไปอยู่ในตัวเราก็ได้

ปล. สำหรับใครที่สงสัยว่า เนยขาว กับ มาการีน ต่างกันยังไง Shortening (เนยขาว) คือไขมันพืช 100% ไม่มีน้ำผสม บีบให้เป็นก้อน ทนความร้อนได้สูง เพื่อให้แป้ง “ไม่ยืด” เกล็ดขนมร่วนกรอบ Margarine (มาการีน) จะผสมไขมันกับน้ำ–เกลือ–อิมัลซิไฟเออร์ ทำให้ทาได้เนียนเหมือนเนย แต่มีน้ำประมาณ 15–20%

#pirateketo #กูต้องรู้มั๊ย #ม้วนหางสิลูก #siamstr

@ 5f078e90:b2bacaa3

Panda story 1

Initially posted on Hive, story is between 300 and 500 characters. Should become a Nostr kind 30023. Image has markdown.

In a misty bamboo forest, a red panda named Rolo discovered a glowing berry. Curious, he nibbled it and began to float! Drifting over treetops, he saw his friends below, waving. Rolo somersaulted through clouds, giggling as wind tickled his fur. The berry's magic faded at dusk, landing him softly by a stream. His pals cheered his tale, and Rolo dreamed of more adventures, his heart light as the breeze. (349 characters)

---

Originally posted on Hive at https://hive.blog/@hostr/panda-story-1

Cross-posted using Hostr, version 0.0.1

@ 3bf0c63f:aefa459d

Pequenos problemas que o Estado cria para a sociedade e que não são sempre lembrados

- **vale-transporte**: transferir o custo com o transporte do funcionário para um terceiro o estimula a morar longe de onde trabalha, já que morar perto é normalmente mais caro e a economia com transporte é inexistente.
- **atestado médico**: o direito a faltar o trabalho com atestado médico cria a exigência desse atestado para todas as situações, substituindo o livre acordo entre patrão e empregado e sobrecarregando os médicos e postos de saúde com visitas desnecessárias de assalariados resfriados.
- **prisões**: com dinheiro mal-administrado, burocracia e péssima alocação de recursos -- problemas que empresas privadas em competição (ou mesmo sem qualquer competição) saberiam resolver muito melhor -- o Estado fica sem presídios, com os poucos existentes entupidos, muito acima de sua alocação máxima, e com isto, segundo a bizarra corrente de responsabilidades que culpa o juiz que condenou o criminoso por sua morte na cadeia, juízes deixam de condenar à prisão os bandidos, soltando-os na rua.
- **justiça**: entrar com processos é grátis e isto faz proliferar a atividade dos advogados que se dedicam a criar problemas judiciais onde não seria necessário e a entupir os tribunais, impedindo-os de fazer o que mais deveriam fazer.
- **justiça**: como a justiça só obedece às leis e ignora acordos pessoais, escritos ou não, as pessoas não fazem acordos, recorrem sempre à justiça estatal, e entopem-na de assuntos que seriam muito melhor resolvidos entre vizinhos.
- **leis civis**: as leis criadas pelos parlamentares ignoram os costumes da sociedade e são um incentivo a que as pessoas não respeitem nem criem normas sociais -- que seriam maneiras mais rápidas, baratas e satisfatórias de resolver problemas.
- **leis de trãnsito**: quanto mais leis de trânsito, mais serviço de fiscalização são delegados aos policiais, que deixam de combater crimes por isto (afinal de contas, eles não querem de fato arriscar suas vidas combatendo o crime, a fiscalização é uma excelente desculpa para se esquivarem a esta responsabilidade).
- **financiamento educacional**: é uma espécie de subsídio às faculdades privadas que faz com que se criem cursos e mais cursos que são cada vez menos recheados de algum conhecimento ou técnica útil e cada vez mais inúteis.
- **leis de tombamento**: são um incentivo a que o dono de qualquer área ou construção "histórica" destrua todo e qualquer vestígio de história que houver nele antes que as autoridades descubram, o que poderia não acontecer se ele pudesse, por exemplo, usar, mostrar e se beneficiar da história daquele local sem correr o risco de perder, de fato, a sua propriedade.
- **zoneamento urbano**: torna as cidades mais espalhadas, criando uma necessidade gigantesca de carros, ônibus e outros meios de transporte para as pessoas se locomoverem das zonas de moradia para as zonas de trabalho.
- **zoneamento urbano**: faz com que as pessoas percam horas no trânsito todos os dias, o que é, além de um desperdício, um atentado contra a sua saúde, que estaria muito melhor servida numa caminhada diária entre a casa e o trabalho.
- **zoneamento urbano**: torna ruas e as casas menos seguras criando zonas enormes, tanto de residências quanto de indústrias, onde não há movimento de gente alguma.
- **escola obrigatória + currículo escolar nacional**: emburrece todas as crianças.
- **leis contra trabalho infantil**: tira das crianças a oportunidade de aprender ofícios úteis e levar um dinheiro para ajudar a família.
- **licitações**: como não existem os critérios do mercado para decidir qual é o melhor prestador de serviço, criam-se comissões de pessoas que vão decidir coisas. isto incentiva os prestadores de serviço que estão concorrendo na licitação a tentar comprar os membros dessas comissões. isto, fora a corrupção, gera problemas reais: __(i)__ a escolha dos serviços acaba sendo a pior possível, já que a empresa prestadora que vence está claramente mais dedicada a comprar comissões do que a fazer um bom trabalho (este problema afeta tantas áreas, desde a construção de estradas até a qualidade da merenda escolar, que é impossível listar aqui); __(ii)__ o processo corruptor acaba, no longo prazo, eliminando as empresas que prestavam e deixando para competir apenas as corruptas, e a qualidade tende a piorar progressivamente.
- **cartéis**: o Estado em geral cria e depois fica refém de vários grupos de interesse. o caso dos taxistas contra o Uber é o que está na moda hoje (e o que mostra como os Estados se comportam da mesma forma no mundo todo).
- **multas**: quando algum indivíduo ou empresa comete uma fraude financeira, ou causa algum dano material involuntário, as vítimas do caso são as pessoas que sofreram o dano ou perderam dinheiro, mas o Estado tem sempre leis que prevêem multas para os responsáveis. A justiça estatal é sempre muito rígida e rápida na aplicação dessas multas, mas relapsa e vaga no que diz respeito à indenização das vítimas. O que em geral acontece é que o Estado aplica uma enorme multa ao responsável pelo mal, retirando deste os recursos que dispunha para indenizar as vítimas, e se retira do caso, deixando estas desamparadas.
- **desapropriação**: o Estado pode pegar qualquer propriedade de qualquer pessoa mediante uma indenização que é necessariamente inferior ao valor da propriedade para o seu presente dono (caso contrário ele a teria vendido voluntariamente).
- **seguro-desemprego**: se há, por exemplo, um prazo mínimo de 1 ano para o sujeito ter direito a receber seguro-desemprego, isto o incentiva a planejar ficar apenas 1 ano em cada emprego (ano este que será sucedido por um período de desemprego remunerado), matando todas as possibilidades de aprendizado ou aquisição de experiência naquela empresa específica ou ascensão hierárquica.
- **previdência**: a previdência social tem todos os defeitos de cálculo do mundo, e não importa muito ela ser uma forma horrível de poupar dinheiro, porque ela tem garantias bizarras de longevidade fornecidas pelo Estado, além de ser compulsória. Isso serve para criar no imaginário geral a idéia da __aposentadoria__, uma época mágica em que todos os dias serão finais de semana. A idéia da aposentadoria influencia o sujeito a não se preocupar em ter um emprego que faça sentido, mas sim em ter um trabalho qualquer, que o permita se aposentar.
- **regulamentação impossível**: milhares de coisas são proibidas, há regulamentações sobre os aspectos mais mínimos de cada empreendimento ou construção ou espaço. se todas essas regulamentações fossem exigidas não haveria condições de produção e todos morreriam. portanto, elas não são exigidas. porém, o Estado, ou um agente individual imbuído do poder estatal pode, se desejar, exigi-las todas de um cidadão inimigo seu. qualquer pessoa pode viver a vida inteira sem cumprir nem 10% das regulamentações estatais, mas viverá também todo esse tempo com medo de se tornar um alvo de sua exigência, num estado de terror psicológico.
- **perversão de critérios**: para muitas coisas sobre as quais a sociedade normalmente chegaria a um valor ou comportamento "razoável" espontaneamente, o Estado dita regras. estas regras muitas vezes não são obrigatórias, são mais "sugestões" ou limites, como o salário mínimo, ou as 44 horas semanais de trabalho. a sociedade, porém, passa a usar esses valores como se fossem o normal. são raras, por exemplo, as ofertas de emprego que fogem à regra das 44h semanais.
- **inflação**: subir os preços é difícil e constrangedor para as empresas, pedir aumento de salário é difícil e constrangedor para o funcionário. a inflação força as pessoas a fazer isso, mas o aumento não é automático, como alguns economistas podem pensar (enquanto alguns outros ficam muito satisfeitos de que esse processo seja demorado e difícil).
- **inflação**: a inflação destrói a capacidade das pessoas de julgar preços entre concorrentes usando a própria memória.
- **inflação**: a inflação destrói os cálculos de lucro/prejuízo das empresas e prejudica enormemente as decisões empresariais que seriam baseadas neles.
- **inflação**: a inflação redistribui a riqueza dos mais pobres e mais afastados do sistema financeiro para os mais ricos, os bancos e as megaempresas.
- **inflação**: a inflação estimula o endividamento e o consumismo.
- **lixo:** ao prover coleta e armazenamento de lixo "grátis para todos" o Estado incentiva a criação de lixo. se tivessem que pagar para que recolhessem o seu lixo, as pessoas (e conseqüentemente as empresas) se empenhariam mais em produzir coisas usando menos plástico, menos embalagens, menos sacolas.
- **leis contra crimes financeiros:** ao criar legislação para dificultar acesso ao sistema financeiro por parte de criminosos a dificuldade e os custos para acesso a esse mesmo sistema pelas pessoas de bem cresce absurdamente, levando a um percentual enorme de gente incapaz de usá-lo, para detrimento de todos -- e no final das contas os grandes criminosos ainda conseguem burlar tudo.

@ 044da344:073a8a0e

„Huch, das ist ja heute schon wieder vier Jahre her“, hat Dietrich Brüggemann am Dienstag auf X gestöhnt. Und: „Ich für meinen Teil würde es wieder tun.“ Knapp 1400 Herzchen und gut 300 Retweets. Immerhin, einerseits. Andererseits scheint die Aktion #allesdichtmachen verschwunden zu sein aus dem kollektiven Gedächtnis. Es gibt eine Seite auf Rumble, die alle 52 Videos dokumentiert. Zwölf Follower und ein paar Klicks. 66 zum Beispiel für die großartige Kathrin Osterode und ihre Idee, die Inzidenzen in das Familienleben zu tragen und im Fall der Fälle auch die Kinder wegzugeben.

Vielleicht sind es auch schon ein paar mehr, wenn Sie jetzt klicken sollten, um jenen späten April-Abend von 2021 zurückzuholen und das Glück, das zum Greifen nah schien. Ich sehe mich noch auf der Couch sitzen, bereit für das Bett, als der Link kam. Ich konnte nicht mehr aufhören. Prominente, endlich. Und auch noch so viele und so gut. Was daraus geworden ist, habe ich genau ein Jahr später mit Freunden und Kollegen in ein Buch gepackt – noch so ein Versuch, ein Ereignis für die Ewigkeit festzuhalten, das die Öffentlichkeit verändert hat und damit das Land, ein Versuch, der genauso in einer Nische versandet ist wie die Rumble-Seite.

Ich fürchte: Auch beim fünften Geburtstag wird sich niemand an #allesdichtmachen erinnern wollen, abgesehen natürlich von Dietrich Brüggemann und ein paar Ewiggestrigen wie mir. Eigentlich lieben Medien Jahrestage, besonders die runden. Weißt Du noch? Heute vor zehn Jahren? In jedem von uns wohnt ein Nostalgiker, der zurückblicken will, Bilanz ziehen möchte, Ankerpunkte sucht im Strom der Zeit. Die Redaktionen wissen das. Sie sehen es mittlerweile auch, weil sie alles erfassen lassen, was wir mit ihren Beiträgen tun. Die blinkenden Bildschirme in den Meinungsfabriken sagen: Jahrestage gehen immer.

Meine These: #allesdichtmachen bricht diese Regel, obwohl die Aktion alles mitbringt, wonach der Journalismus sucht. Prominenz, Konflikt und Drama mit allem Drum und Dran. Leidenschaft, Tränen und – ja, auch eine historische Dimension. Falls unsere Enkel noch Kulturgeschichten schreiben dürfen, werden sie Brüggemann & Co. nicht aussparen können. Wo gibt es das schon – eine Kunstaktion, die das Land verändert? Nach diesen fünf Tagen im April 2021 wussten alle, wie die Kräfte im Land verteilt sind. Das Wort Diskussionskultur wurde aus dem Duden gestrichen. Und jeder Überlebende der Anti-Axel-Springer-Demos konnte sehen, dass alle Träume der Achtundsechziger wahr geworden sind. Die Bildzeitung hat nichts mehr zu sagen. Etwas akademischer gesprochen: Die Definitionsmachtverhältnisse haben sich geändert – weg von dem Blatt mit den großen Buchstaben und damit von Milieus ohne akademische Abschlüsse oder Bürojobs, hin zu den Leitmedien der Menschen, die in irgendeiner Weise vom Staat abhängen und deshalb Zeit haben, sich eine Wirklichkeit zurechtzutwittern.

Der Reihe nach. 22. April 2021, ein Donnerstag. 15 Minuten vor Mitternacht erscheint #allesdichtmachen in der Onlineausgabe der Bildzeitung. O-Ton: „Mit Ironie, Witz und Sarkasmus hinterfragen Deutschlands bekannteste Schauspielerinnen und Schauspieler die Corona-Politik der Bundesregierung und kritisieren die hiesige Diskussionskultur.“

Die 53 Videos sind da erst ein paar Stunden online, aber zumindest auf der „Haupt-Website der Aktion“ schon nicht mehr abrufbar. „Offenbar gehacked“, schreibt die Bildzeitung und wirbt für YouTube. Außerdem gibt es positive Reaktionen (etwa vom Virologen Jonas Schmidt-Chanasit, der von einem „Meisterwerk“ gesprochen habe) sowie einen Ausblick auf das, was die Leitmedien dann dominieren wird: „Manche User auf Twitter und Facebook versuchen, die Aktion in die Coronaleugner-Ecke zu rücken. Dabei leugnet keiner der Schauspielerinnen und Schauspieler auch nur ansatzweise die Existenz des Coronavirus.“

Heute wissen wir: Bild setzte hier zwar ein Thema, aber nicht den Ton. Anders gesagt: Was am Donnerstagabend noch zu gelten scheint, ist am Freitag nicht mehr wahr. „Wenn man seinen eigenen Shitstorm verschlafen hat“, twittert Manuel Rubey am nächsten Morgen, ein Schauspieler aus Österreich, der in seinem Video fordert, „die Theater, die Museen, die Kinos, die Kabarettbühnen überhaupt nie wieder aufzusperren“. Eine Woche später erklärt Rubey im Wiener Standard seinen Tweet. Gleich nach der Veröffentlichung habe er vor dem Schlafengehen „noch ein bisschen Kommentare gelesen“ und „das Gefühl“ gehabt, „dass es verstanden wird, wie es gemeint war“. Der Tag danach: „ein kafkaesker Albtraum. Kollegen entschuldigten sich privat, dass sie ihre positiven Kommentare nun doch gelöscht hätten.“

An der Bildzeitung hat das nicht gelegen. Die Redaktion blieb bei ihrer Linie und bot Dietrich Brüggemann an Tag fünf (Montag) eine Video-Bühne für eine Art Schlusswort zur Debatte (Länge: über zwölf Minuten), ohne den Regisseur zu denunzieren. Vorher finden sich hier Stimmen, die sonst nirgendwo zu hören waren – etwa Peter-Michael Diestel, letzter DDR-Innenminister, der die „Diskussionskultur beschädigt“ sieht, oder eine PR-Agentin, die ihren „Klienten abgeraten“ hat, „sich in den Sturm zu stellen“.

Geschossen wurde aus allen Rohren – auf Twitter und in den anderen Leitmedien. Tenor: Die Kritik ist ungerechtfertigt und schädlich. Den Beteiligten wurde vorgeworfen, „zynisch“ und „hämisch“ zu sein, die Gesellschaft zu spalten, ohne etwas „Konstruktives“ beizutragen, und nur an sich selbst und „ihre eigene Lage“ zu denken. Dabei wurden Vorurteile gegen Kunst und Künstler aktiviert und Rufmorde inszeniert. „Für mich ist das Kunst aus dem Elfenbeinturm der Privilegierten, ein elitäres Gewimmer“, sagte die Schauspielerin Pegah Ferydoni der Süddeutschen Zeitung. Michael Hanfeld bescheinigte den Schauspielprofis in der FAZ, ihre Texte „peinlich aufgesagt“ zu haben. In der Zeit fiel das Wort „grauenhaft“, und eine Spiegel– Videokolumne sprach sogar von „Waschmittelwerbung“.

In der Bildzeitung ließen Überschriften und Kommentare dagegen keinen Zweifel, wo die Sympathien der Redaktion liegen. „Filmakademie-Präsident geht auf Kollegen los“ steht über der Meldung, dass Ulrich Matthes die Aktion kritisiert hat. Dachzeile: „‚Zynisch‘, ‚komplett naiv und ballaballa‘“. Auf dem Foto wirkt Matthes arrogant und abgehoben – wie ein Köter, der um sich beißt. „Ich bin ein #allesdichtmachen-Fan“, schreibt Bild-Urgestein Franz-Josef Wagner am 25. April über seine Kolumne.

Mehr als zwei Dutzend Artikel über dieses lange Wochenende, die meisten davon Pro. Ralf Schuler, damals dort noch Leiter der Parlamentsredaktion und in jeder Hinsicht ein Schwergewicht, äußert sich gleich zweimal. „Großes Kino!“ sagt er am 23. April. Am nächsten Tag versteht Schuler sein Land nicht mehr: „53 Top-Künstler greifen in Videos die Corona-Stimmung im Lande auf: Kontakt- und Ausgangssperre, Alarmismus, Denunziantentum, wirtschaftliche Not und Ohnmachtsgefühle. Die Antwort: Hass, Shitstorm und ein SPD-Politiker denkt sogar öffentlich über Berufsverbote für die beteiligten Schauspieler nach. Binnen Stunden ziehen die ersten verschreckt ihre Videos zurück, andere distanzieren sich, müssen öffentlich Rechtfertigungen abgeben. Geht’s noch?“ Weiter bei Schuler: „Es ist Aufgabe von Kunst und Satire, dahin zu zielen, wo es wehtut, Stimmungen aufzugreifen und aufzubrechen, Machtworte zu ignorieren und dem Virus nicht das letzte Wort zu lassen. Auch, wenn ein Teil des Zuspruchs von schriller, schräger oder politisch unappetitlicher Seite kommt. Das überhaupt erwähnen zu müssen, beschreibt bereits das Problem: eine Politik, die ihr Tun für alternativlos, ultimativ und einzig wahr hält und Kritiker in den Verdacht stellt, Tod über Deutschland bringen zu wollen.“

Immerhin: Der Lack war endgültig ab von dieser Demokratie. Die Aktion #allesdichtmachen war ein Lehrstück. Rally around the flag, wann immer es die da oben befehlen. Lasst uns in den Kampf ziehen. Gestern gegen ein Virus, heute gegen die Russen und morgen gegen die ganze Welt – oder wenigstens gegen alle, die Fragen stellen, Zweifel haben, nicht laut Hurra rufen. Innerer Frieden? Ab auf den Müllhaufen der Geschichte. Wir sollten diesen Jahrestag feiern, immer wieder.

Bildquellen: Screenshots von Daria Gordeeva. Titel: Dietrich Brüggemann, Text: Kathrin Osterode

Michael Meyen: Videos

Freie Akademie für Medien & Journalismus

Unterstützen

@ 21335073:a244b1ad

Warning: This piece contains a conversation about difficult topics. Please proceed with caution.

TL;DR please educate your children about online safety.

Julian Assange wrote in his 2012 book Cypherpunks, “This book is not a manifesto. There isn’t time for that. This book is a warning.” I read it a few times over the past summer. Those opening lines definitely stood out to me. I wish we had listened back then. He saw something about the internet that few had the ability to see. There are some individuals who are so close to a topic that when they speak, it’s difficult for others who aren’t steeped in it to visualize what they’re talking about. I didn’t read the book until more recently. If I had read it when it came out, it probably would have sounded like an unknown foreign language to me. Today it makes more sense.

This isn’t a manifesto. This isn’t a book. There is no time for that. It’s a warning and a possible solution from a desperate and determined survivor advocate who has been pulling and unraveling a thread for a few years. At times, I feel too close to this topic to make any sense trying to convey my pathway to my conclusions or thoughts to the general public. My hope is that if nothing else, I can convey my sense of urgency while writing this. This piece is a watchman’s warning.

When a child steps online, they are walking into a new world. A new reality. When you hand a child the internet, you are handing them possibilities—good, bad, and ugly. This is a conversation about lowering the potential of negative outcomes of stepping into that new world and how I came to these conclusions. I constantly compare the internet to the road. You wouldn’t let a young child run out into the road with no guidance or safety precautions. When you hand a child the internet without any type of guidance or safety measures, you are allowing them to play in rush hour, oncoming traffic. “Look left, look right for cars before crossing.” We almost all have been taught that as children. What are we taught as humans about safety before stepping into a completely different reality like the internet? Very little.

I could never really figure out why many folks in tech, privacy rights activists, and hackers seemed so cold to me while talking about online child sexual exploitation. I always figured that as a survivor advocate for those affected by these crimes, that specific, skilled group of individuals would be very welcoming and easy to talk to about such serious topics. I actually had one hacker laugh in my face when I brought it up while I was looking for answers. I thought maybe this individual thought I was accusing them of something I wasn’t, so I felt bad for asking. I was constantly extremely disappointed and would ask myself, “Why don’t they care? What could I say to make them care more? What could I say to make them understand the crisis and the level of suffering that happens as a result of the problem?”

I have been serving minor survivors of online child sexual exploitation for years. My first case serving a survivor of this specific crime was in 2018—a 13-year-old girl sexually exploited by a serial predator on Snapchat. That was my first glimpse into this side of the internet. I won a national award for serving the minor survivors of Twitter in 2023, but I had been working on that specific project for a few years. I was nominated by a lawyer representing two survivors in a legal battle against the platform. I’ve never really spoken about this before, but at the time it was a choice for me between fighting Snapchat or Twitter. I chose Twitter—or rather, Twitter chose me. I heard about the story of John Doe #1 and John Doe #2, and I was so unbelievably broken over it that I went to war for multiple years. I was and still am royally pissed about that case. As far as I was concerned, the John Doe #1 case proved that whatever was going on with corporate tech social media was so out of control that I didn’t have time to wait, so I got to work. It was reading the messages that John Doe #1 sent to Twitter begging them to remove his sexual exploitation that broke me. He was a child begging adults to do something. A passion for justice and protecting kids makes you do wild things. I was desperate to find answers about what happened and searched for solutions. In the end, the platform Twitter was purchased. During the acquisition, I just asked Mr. Musk nicely to prioritize the issue of detection and removal of child sexual exploitation without violating digital privacy rights or eroding end-to-end encryption. Elon thanked me multiple times during the acquisition, made some changes, and I was thanked by others on the survivors’ side as well.

I still feel that even with the progress made, I really just scratched the surface with Twitter, now X. I left that passion project when I did for a few reasons. I wanted to give new leadership time to tackle the issue. Elon Musk made big promises that I knew would take a while to fulfill, but mostly I had been watching global legislation transpire around the issue, and frankly, the governments are willing to go much further with X and the rest of corporate tech than I ever would. My work begging Twitter to make changes with easier reporting of content, detection, and removal of child sexual exploitation material—without violating privacy rights or eroding end-to-end encryption—and advocating for the minor survivors of the platform went as far as my principles would have allowed. I’m grateful for that experience. I was still left with a nagging question: “How did things get so bad with Twitter where the John Doe #1 and John Doe #2 case was able to happen in the first place?” I decided to keep looking for answers. I decided to keep pulling the thread.

I never worked for Twitter. This is often confusing for folks. I will say that despite being disappointed in the platform’s leadership at times, I loved Twitter. I saw and still see its value. I definitely love the survivors of the platform, but I also loved the platform. I was a champion of the platform’s ability to give folks from virtually around the globe an opportunity to speak and be heard.

I want to be clear that John Doe #1 really is my why. He is the inspiration. I am writing this because of him. He represents so many globally, and I’m still inspired by his bravery. One child’s voice begging adults to do something—I’m an adult, I heard him. I’d go to war a thousand more lifetimes for that young man, and I don’t even know his name. Fighting has been personally dark at times; I’m not even going to try to sugarcoat it, but it has been worth it.

The data surrounding the very real crime of online child sexual exploitation is available to the public online at any time for anyone to see. I’d encourage you to go look at the data for yourself. I believe in encouraging folks to check multiple sources so that you understand the full picture. If you are uncomfortable just searching around the internet for information about this topic, use the terms “CSAM,” “CSEM,” “SG-CSEM,” or “AI Generated CSAM.” The numbers don’t lie—it’s a nightmare that’s out of control. It’s a big business. The demand is high, and unfortunately, business is booming. Organizations collect the data, tech companies often post their data, governments report frequently, and the corporate press has covered a decent portion of the conversation, so I’m sure you can find a source that you trust.

Technology is changing rapidly, which is great for innovation as a whole but horrible for the crime of online child sexual exploitation. Those wishing to exploit the vulnerable seem to be adapting to each technological change with ease. The governments are so far behind with tackling these issues that as I’m typing this, it’s borderline irrelevant to even include them while speaking about the crime or potential solutions. Technology is changing too rapidly, and their old, broken systems can’t even dare to keep up. Think of it like the governments’ “War on Drugs.” Drugs won. In this case as well, the governments are not winning. The governments are talking about maybe having a meeting on potentially maybe having legislation around the crimes. The time to have that meeting would have been many years ago. I’m not advocating for governments to legislate our way out of this. I’m on the side of educating and innovating our way out of this.

I have been clear while advocating for the minor survivors of corporate tech platforms that I would not advocate for any solution to the crime that would violate digital privacy rights or erode end-to-end encryption. That has been a personal moral position that I was unwilling to budge on. This is an extremely unpopular and borderline nonexistent position in the anti-human trafficking movement and online child protection space. I’m often fearful that I’m wrong about this. I have always thought that a better pathway forward would have been to incentivize innovation for detection and removal of content. I had no previous exposure to privacy rights activists or Cypherpunks—actually, I came to that conclusion by listening to the voices of MENA region political dissidents and human rights activists. After developing relationships with human rights activists from around the globe, I realized how important privacy rights and encryption are for those who need it most globally. I was simply unwilling to give more power, control, and opportunities for mass surveillance to big abusers like governments wishing to enslave entire nations and untrustworthy corporate tech companies to potentially end some portion of abuses online. On top of all of it, it has been clear to me for years that all potential solutions outside of violating digital privacy rights to detect and remove child sexual exploitation online have not yet been explored aggressively. I’ve been disappointed that there hasn’t been more of a conversation around preventing the crime from happening in the first place.

What has been tried is mass surveillance. In China, they are currently under mass surveillance both online and offline, and their behaviors are attached to a social credit score. Unfortunately, even on state-run and controlled social media platforms, they still have child sexual exploitation and abuse imagery pop up along with other crimes and human rights violations. They also have a thriving black market online due to the oppression from the state. In other words, even an entire loss of freedom and privacy cannot end the sexual exploitation of children online. It’s been tried. There is no reason to repeat this method.

It took me an embarrassingly long time to figure out why I always felt a slight coldness from those in tech and privacy-minded individuals about the topic of child sexual exploitation online. I didn’t have any clue about the “Four Horsemen of the Infocalypse.” This is a term coined by Timothy C. May in 1988. I would have been a child myself when he first said it. I actually laughed at myself when I heard the phrase for the first time. I finally got it. The Cypherpunks weren’t wrong about that topic. They were so spot on that it is borderline uncomfortable. I was mad at first that they knew that early during the birth of the internet that this issue would arise and didn’t address it. Then I got over it because I realized that it wasn’t their job. Their job was—is—to write code. Their job wasn’t to be involved and loving parents or survivor advocates. Their job wasn’t to educate children on internet safety or raise awareness; their job was to write code.

They knew that child sexual abuse material would be shared on the internet. They said what would happen—not in a gleeful way, but a prediction. Then it happened.

I equate it now to a concrete company laying down a road. As you’re pouring the concrete, you can say to yourself, “A terrorist might travel down this road to go kill many, and on the flip side, a beautiful child can be born in an ambulance on this road.” Who or what travels down the road is not their responsibility—they are just supposed to lay the concrete. I’d never go to a concrete pourer and ask them to solve terrorism that travels down roads. Under the current system, law enforcement should stop terrorists before they even make it to the road. The solution to this specific problem is not to treat everyone on the road like a terrorist or to not build the road.

So I understand the perceived coldness from those in tech. Not only was it not their job, but bringing up the topic was seen as the equivalent of asking a free person if they wanted to discuss one of the four topics—child abusers, terrorists, drug dealers, intellectual property pirates, etc.—that would usher in digital authoritarianism for all who are online globally.

Privacy rights advocates and groups have put up a good fight. They stood by their principles. Unfortunately, when it comes to corporate tech, I believe that the issue of privacy is almost a complete lost cause at this point. It’s still worth pushing back, but ultimately, it is a losing battle—a ticking time bomb.

I do think that corporate tech providers could have slowed down the inevitable loss of privacy at the hands of the state by prioritizing the detection and removal of CSAM when they all started online. I believe it would have bought some time, fewer would have been traumatized by that specific crime, and I do believe that it could have slowed down the demand for content. If I think too much about that, I’ll go insane, so I try to push the “if maybes” aside, but never knowing if it could have been handled differently will forever haunt me. At night when it’s quiet, I wonder what I would have done differently if given the opportunity. I’ll probably never know how much corporate tech knew and ignored in the hopes that it would go away while the problem continued to get worse. They had different priorities. The most voiceless and vulnerable exploited on corporate tech never had much of a voice, so corporate tech providers didn’t receive very much pushback.

Now I’m about to say something really wild, and you can call me whatever you want to call me, but I’m going to say what I believe to be true. I believe that the governments are either so incompetent that they allowed the proliferation of CSAM online, or they knowingly allowed the problem to fester long enough to have an excuse to violate privacy rights and erode end-to-end encryption. The US government could have seized the corporate tech providers over CSAM, but I believe that they were so useful as a propaganda arm for the regimes that they allowed them to continue virtually unscathed.

That season is done now, and the governments are making the issue a priority. It will come at a high cost. Privacy on corporate tech providers is virtually done as I’m typing this. It feels like a death rattle. I’m not particularly sure that we had much digital privacy to begin with, but the illusion of a veil of privacy feels gone.

To make matters slightly more complex, it would be hard to convince me that once AI really gets going, digital privacy will exist at all.

I believe that there should be a conversation shift to preserving freedoms and human rights in a post-privacy society.

I don’t want to get locked up because AI predicted a nasty post online from me about the government. I’m not a doomer about AI—I’m just going to roll with it personally. I’m looking forward to the positive changes that will be brought forth by AI. I see it as inevitable. A bit of privacy was helpful while it lasted. Please keep fighting to preserve what is left of privacy either way because I could be wrong about all of this.

On the topic of AI, the addition of AI to the horrific crime of child sexual abuse material and child sexual exploitation in multiple ways so far has been devastating. It’s currently out of control. The genie is out of the bottle. I am hopeful that innovation will get us humans out of this, but I’m not sure how or how long it will take. We must be extremely cautious around AI legislation. It should not be illegal to innovate even if some bad comes with the good. I don’t trust that the governments are equipped to decide the best pathway forward for AI. Source: the entire history of the government.

I have been personally negatively impacted by AI-generated content. Every few days, I get another alert that I’m featured again in what’s called “deep fake pornography” without my consent. I’m not happy about it, but what pains me the most is the thought that for a period of time down the road, many globally will experience what myself and others are experiencing now by being digitally sexually abused in this way. If you have ever had your picture taken and posted online, you are also at risk of being exploited in this way. Your child’s image can be used as well, unfortunately, and this is just the beginning of this particular nightmare. It will move to more realistic interpretations of sexual behaviors as technology improves. I have no brave words of wisdom about how to deal with that emotionally. I do have hope that innovation will save the day around this specific issue. I’m nervous that everyone online will have to ID verify due to this issue. I see that as one possible outcome that could help to prevent one problem but inadvertently cause more problems, especially for those living under authoritarian regimes or anyone who needs to remain anonymous online. A zero-knowledge proof (ZKP) would probably be the best solution to these issues. There are some survivors of violence and/or sexual trauma who need to remain anonymous online for various reasons. There are survivor stories available online of those who have been abused in this way. I’d encourage you seek out and listen to their stories.

There have been periods of time recently where I hesitate to say anything at all because more than likely AI will cover most of my concerns about education, awareness, prevention, detection, and removal of child sexual exploitation online, etc.

Unfortunately, some of the most pressing issues we’ve seen online over the last few years come in the form of “sextortion.” Self-generated child sexual exploitation (SG-CSEM) numbers are continuing to be terrifying. I’d strongly encourage that you look into sextortion data. AI + sextortion is also a huge concern. The perpetrators are using the non-sexually explicit images of children and putting their likeness on AI-generated child sexual exploitation content and extorting money, more imagery, or both from minors online. It’s like a million nightmares wrapped into one. The wild part is that these issues will only get more pervasive because technology is harnessed to perpetuate horror at a scale unimaginable to a human mind.

Even if you banned phones and the internet or tried to prevent children from accessing the internet, it wouldn’t solve it. Child sexual exploitation will still be with us until as a society we start to prevent the crime before it happens. That is the only human way out right now.

There is no reset button on the internet, but if I could go back, I’d tell survivor advocates to heed the warnings of the early internet builders and to start education and awareness campaigns designed to prevent as much online child sexual exploitation as possible. The internet and technology moved quickly, and I don’t believe that society ever really caught up. We live in a world where a child can be groomed by a predator in their own home while sitting on a couch next to their parents watching TV. We weren’t ready as a species to tackle the fast-paced algorithms and dangers online. It happened too quickly for parents to catch up. How can you parent for the ever-changing digital world unless you are constantly aware of the dangers?

I don’t think that the internet is inherently bad. I believe that it can be a powerful tool for freedom and resistance. I’ve spoken a lot about the bad online, but there is beauty as well. We often discuss how victims and survivors are abused online; we rarely discuss the fact that countless survivors around the globe have been able to share their experiences, strength, hope, as well as provide resources to the vulnerable. I do question if giving any government or tech company access to censorship, surveillance, etc., online in the name of serving survivors might not actually impact a portion of survivors negatively. There are a fair amount of survivors with powerful abusers protected by governments and the corporate press. If a survivor cannot speak to the press about their abuse, the only place they can go is online, directly or indirectly through an independent journalist who also risks being censored. This scenario isn’t hard to imagine—it already happened in China. During #MeToo, a survivor in China wanted to post their story. The government censored the post, so the survivor put their story on the blockchain. I’m excited that the survivor was creative and brave, but it’s terrifying to think that we live in a world where that situation is a necessity.

I believe that the future for many survivors sharing their stories globally will be on completely censorship-resistant and decentralized protocols. This thought in particular gives me hope. When we listen to the experiences of a diverse group of survivors, we can start to understand potential solutions to preventing the crimes from happening in the first place.

My heart is broken over the gut-wrenching stories of survivors sexually exploited online. Every time I hear the story of a survivor, I do think to myself quietly, “What could have prevented this from happening in the first place?” My heart is with survivors.

My head, on the other hand, is full of the understanding that the internet should remain free. The free flow of information should not be stopped. My mind is with the innocent citizens around the globe that deserve freedom both online and offline.

The problem is that governments don’t only want to censor illegal content that violates human rights—they create legislation that is so broad that it can impact speech and privacy of all. “Don’t you care about the kids?” Yes, I do. I do so much that I’m invested in finding solutions. I also care about all citizens around the globe that deserve an opportunity to live free from a mass surveillance society. If terrorism happens online, I should not be punished by losing my freedom. If drugs are sold online, I should not be punished. I’m not an abuser, I’m not a terrorist, and I don’t engage in illegal behaviors. I refuse to lose freedom because of others’ bad behaviors online.

I want to be clear that on a long enough timeline, the governments will decide that they can be better parents/caregivers than you can if something isn’t done to stop minors from being sexually exploited online. The price will be a complete loss of anonymity, privacy, free speech, and freedom of religion online. I find it rather insulting that governments think they’re better equipped to raise children than parents and caretakers.

So we can’t go backwards—all that we can do is go forward. Those who want to have freedom will find technology to facilitate their liberation. This will lead many over time to decentralized and open protocols. So as far as I’m concerned, this does solve a few of my worries—those who need, want, and deserve to speak freely online will have the opportunity in most countries—but what about online child sexual exploitation?

When I popped up around the decentralized space, I was met with the fear of censorship. I’m not here to censor you. I don’t write code. I couldn’t censor anyone or any piece of content even if I wanted to across the internet, no matter how depraved. I don’t have the skills to do that.

I’m here to start a conversation. Freedom comes at a cost. You must always fight for and protect your freedom. I can’t speak about protecting yourself from all of the Four Horsemen because I simply don’t know the topics well enough, but I can speak about this one topic.

If there was a shortcut to ending online child sexual exploitation, I would have found it by now. There isn’t one right now. I believe that education is the only pathway forward to preventing the crime of online child sexual exploitation for future generations.

I propose a yearly education course for every child of all school ages, taught as a standard part of the curriculum. Ideally, parents/caregivers would be involved in the education/learning process.

Course: - The creation of the internet and computers - The fight for cryptography - The tech supply chain from the ground up (example: human rights violations in the supply chain) - Corporate tech - Freedom tech - Data privacy - Digital privacy rights - AI (history-current) - Online safety (predators, scams, catfishing, extortion) - Bitcoin - Laws - How to deal with online hate and harassment - Information on who to contact if you are being abused online or offline - Algorithms - How to seek out the truth about news, etc., online

The parents/caregivers, homeschoolers, unschoolers, and those working to create decentralized parallel societies have been an inspiration while writing this, but my hope is that all children would learn this course, even in government ran schools. Ideally, parents would teach this to their own children.

The decentralized space doesn’t want child sexual exploitation to thrive. Here’s the deal: there has to be a strong prevention effort in order to protect the next generation. The internet isn’t going anywhere, predators aren’t going anywhere, and I’m not down to let anyone have the opportunity to prove that there is a need for more government. I don’t believe that the government should act as parents. The governments have had a chance to attempt to stop online child sexual exploitation, and they didn’t do it. Can we try a different pathway forward?

I’d like to put myself out of a job. I don’t want to ever hear another story like John Doe #1 ever again. This will require work. I’ve often called online child sexual exploitation the lynchpin for the internet. It’s time to arm generations of children with knowledge and tools. I can’t do this alone.

Individuals have fought so that I could have freedom online. I want to fight to protect it. I don’t want child predators to give the government any opportunity to take away freedom. Decentralized spaces are as close to a reset as we’ll get with the opportunity to do it right from the start. Start the youth off correctly by preventing potential hazards to the best of your ability.

The good news is anyone can work on this! I’d encourage you to take it and run with it. I added the additional education about the history of the internet to make the course more educational and fun. Instead of cleaning up generations of destroyed lives due to online sexual exploitation, perhaps this could inspire generations of those who will build our futures. Perhaps if the youth is armed with knowledge, they can create more tools to prevent the crime.

This one solution that I’m suggesting can be done on an individual level or on a larger scale. It should be adjusted depending on age, learning style, etc. It should be fun and playful.

This solution does not address abuse in the home or some of the root causes of offline child sexual exploitation. My hope is that it could lead to some survivors experiencing abuse in the home an opportunity to disclose with a trusted adult. The purpose for this solution is to prevent the crime of online child sexual exploitation before it occurs and to arm the youth with the tools to contact safe adults if and when it happens.

In closing, I went to hell a few times so that you didn’t have to. I spoke to the mothers of survivors of minors sexually exploited online—their tears could fill rivers. I’ve spoken with political dissidents who yearned to be free from authoritarian surveillance states. The only balance that I’ve found is freedom online for citizens around the globe and prevention from the dangers of that for the youth. Don’t slow down innovation and freedom. Educate, prepare, adapt, and look for solutions.

I’m not perfect and I’m sure that there are errors in this piece. I hope that you find them and it starts a conversation.

@ 3bf0c63f:aefa459d

Drivechain

Understanding Drivechain requires a shift from the paradigm most bitcoiners are used to. It is not about "trustlessness" or "mathematical certainty", but game theory and incentives. (Well, Bitcoin in general is also that, but people prefer to ignore it and focus on some illusion of trustlessness provided by mathematics.)

Here we will describe the basic mechanism (simple) and incentives (complex) of "hashrate escrow" and how it enables a 2-way peg between the mainchain (Bitcoin) and various sidechains.

The full concept of "Drivechain" also involves blind merged mining (i.e., the sidechains mine themselves by publishing their block hashes to the mainchain without the miners having to run the sidechain software), but this is much easier to understand and can be accomplished either by the BIP-301 mechanism or by the Spacechains mechanism.

How does hashrate escrow work from the point of view of Bitcoin?

A new address type is created. Anything that goes in that is locked and can only be spent if all miners agree on the Withdrawal Transaction (WT^) that will spend it for 6 months. There is one of these special addresses for each sidechain.

To gather miners' agreement bitcoind keeps track of the "score" of all transactions that could possibly spend from that address. On every block mined, for each sidechain, the miner can use a portion of their coinbase to either increase the score of one WT^ by 1 while decreasing the score of all others by 1; or they can decrease the score of all WT^s by 1; or they can do nothing.

Once a transaction has gotten a score high enough, it is published and funds are effectively transferred from the sidechain to the withdrawing users.

If a timeout of 6 months passes and the score doesn't meet the threshold, that WT^ is discarded.

What does the above procedure mean?

It means that people can transfer coins from the mainchain to a sidechain by depositing to the special address. Then they can withdraw from the sidechain by making a special withdraw transaction in the sidechain.

The special transaction somehow freezes funds in the sidechain while a transaction that aggregates all withdrawals into a single mainchain WT^, which is then submitted to the mainchain miners so they can start voting on it and finally after some months it is published.

Now the crucial part: the validity of the WT^ is not verified by the Bitcoin mainchain rules, i.e., if Bob has requested a withdraw from the sidechain to his mainchain address, but someone publishes a wrong WT^ that instead takes Bob's funds and sends them to Alice's main address there is no way the mainchain will know that. What determines the "validity" of the WT^ is the miner vote score and only that. It is the job of miners to vote correctly -- and for that they may want to run the sidechain node in SPV mode so they can attest for the existence of a reference to the WT^ transaction in the sidechain blockchain (which then ensures it is ok) or do these checks by some other means.

What? 6 months to get my money back?

Yes. But no, in practice anyone who wants their money back will be able to use an atomic swap, submarine swap or other similar service to transfer funds from the sidechain to the mainchain and vice-versa. The long delayed withdraw costs would be incurred by few liquidity providers that would gain some small profit from it.

Why bother with this at all?

Drivechains solve many different problems:

It enables experimentation and new use cases for Bitcoin

Issued assets, fully private transactions, stateful blockchain contracts, turing-completeness, decentralized games, some "DeFi" aspects, prediction markets, futarchy, decentralized and yet meaningful human-readable names, big blocks with a ton of normal transactions on them, a chain optimized only for Lighting-style networks to be built on top of it.

These are some ideas that may have merit to them, but were never actually tried because they couldn't be tried with real Bitcoin or inferfacing with real bitcoins. They were either relegated to the shitcoin territory or to custodial solutions like Liquid or RSK that may have failed to gain network effect because of that.

It solves conflicts and infighting

Some people want fully private transactions in a UTXO model, others want "accounts" they can tie to their name and build reputation on top; some people want simple multisig solutions, others want complex code that reads a ton of variables; some people want to put all the transactions on a global chain in batches every 10 minutes, others want off-chain instant transactions backed by funds previously locked in channels; some want to spend, others want to just hold; some want to use blockchain technology to solve all the problems in the world, others just want to solve money.

With Drivechain-based sidechains all these groups can be happy simultaneously and don't fight. Meanwhile they will all be using the same money and contributing to each other's ecosystem even unwillingly, it's also easy and free for them to change their group affiliation later, which reduces cognitive dissonance.

It solves "scaling"

Multiple chains like the ones described above would certainly do a lot to accomodate many more transactions that the current Bitcoin chain can. One could have special Lightning Network chains, but even just big block chains or big-block-mimblewimble chains or whatnot could probably do a good job. Or even something less cool like 200 independent chains just like Bitcoin is today, no extra features (and you can call it "sharding"), just that would already multiply the current total capacity by 200.

Use your imagination.

It solves the blockchain security budget issue

The calculation is simple: you imagine what security budget is reasonable for each block in a world without block subsidy and divide that for the amount of bytes you can fit in a single block: that is the price to be paid in satoshis per byte. In reasonable estimative, the price necessary for every Bitcoin transaction goes to very large amounts, such that not only any day-to-day transaction has insanely prohibitive costs, but also Lightning channel opens and closes are impracticable.

So without a solution like Drivechain you'll be left with only one alternative: pushing Bitcoin usage to trusted services like Liquid and RSK or custodial Lightning wallets. With Drivechain, though, there could be thousands of transactions happening in sidechains and being all aggregated into a sidechain block that would then pay a very large fee to be published (via blind merged mining) to the mainchain. Bitcoin security guaranteed.

It keeps Bitcoin decentralized

Once we have sidechains to accomodate the normal transactions, the mainchain functionality can be reduced to be only a "hub" for the sidechains' comings and goings, and then the maximum block size for the mainchain can be reduced to, say, 100kb, which would make running a full node very very easy.

Can miners steal?

Yes. If a group of coordinated miners are able to secure the majority of the hashpower and keep their coordination for 6 months, they can publish a WT^ that takes the money from the sidechains and pays to themselves.

Will miners steal?

No, because the incentives are such that they won't.

Although it may look at first that stealing is an obvious strategy for miners as it is free money, there are many costs involved:

1. The cost of ceasing blind-merged mining returns -- as stealing will kill a sidechain, all the fees from it that miners would be expected to earn for the next years are gone;
2. The cost of Bitcoin price going down: If a steal is successful that will mean Drivechains are not safe, therefore Bitcoin is less useful, and miner credibility will also be hurt, which are likely to cause the Bitcoin price to go down, which in turn may kill the miners' businesses and savings;
3. The cost of coordination -- assuming miners are just normal businesses, they just want to do their work and get paid, but stealing from a Drivechain will require coordination with other miners to conduct an immoral act in a way that has many pitfalls and is likely to be broken over the months;
4. The cost of miners leaving your mining pool: when we talked about "miners" above we were actually talking about mining pools operators, so they must also consider the risk of miners migrating from their mining pool to others as they begin the process of stealing;
5. The cost of community goodwill -- when participating in a steal operation, a miner will suffer a ton of backlash from the community. Even if the attempt fails at the end, the fact that it was attempted will contribute to growing concerns over exaggerated miners power over the Bitcoin ecosystem, which may end up causing the community to agree on a hard-fork to change the mining algorithm in the future, or to do something to increase participation of more entities in the mining process (such as development or cheapment of new ASICs), which have a chance of decreasing the profits of current miners.

Another point to take in consideration is that one may be inclined to think a newly-created sidechain or a sidechain with relatively low usage may be more easily stolen from, since the blind merged mining returns from it (point 1 above) are going to be small -- but the fact is also that a sidechain with small usage will also have less money to be stolen from, and since the other costs besides 1 are less elastic at the end it will not be worth stealing from these too.

All of the above consideration are valid only if miners are stealing from good sidechains. If there is a sidechain that is doing things wrong, scamming people, not being used at all, or is full of bugs, for example, that will be perceived as a bad sidechain, and then miners can and will safely steal from it and kill it, which will be perceived as a good thing by everybody.

What do we do if miners steal?

Paul Sztorc has suggested in the past that a user-activated soft-fork could prevent miners from stealing, i.e., most Bitcoin users and nodes issue a rule similar to this one to invalidate the inclusion of a faulty WT^ and thus cause any miner that includes it in a block to be relegated to their own Bitcoin fork that other nodes won't accept.

This suggestion has made people think Drivechain is a sidechain solution backed by user-actived soft-forks for safety, which is very far from the truth. Drivechains must not and will not rely on this kind of soft-fork, although they are possible, as the coordination costs are too high and no one should ever expect these things to happen.

If even with all the incentives against them (see above) miners do still steal from a good sidechain that will mean the failure of the Drivechain experiment. It will very likely also mean the failure of the Bitcoin experiment too, as it will be proven that miners can coordinate to act maliciously over a prolonged period of time regardless of economic and social incentives, meaning they are probably in it just for attacking Bitcoin, backed by nation-states or something else, and therefore no Bitcoin transaction in the mainchain is to be expected to be safe ever again.

Why use this and not a full-blown trustless and open sidechain technology?

Because it is impossible.

If you ever heard someone saying "just use a sidechain", "do this in a sidechain" or anything like that, be aware that these people are either talking about "federated" sidechains (i.e., funds are kept in custody by a group of entities) or they are talking about Drivechain, or they are disillusioned and think it is possible to do sidechains in any other manner.

No, I mean a trustless 2-way peg with correctness of the withdrawals verified by the Bitcoin protocol!

That is not possible unless Bitcoin verifies all transactions that happen in all the sidechains, which would be akin to drastically increasing the blocksize and expanding the Bitcoin rules in tons of ways, i.e., a terrible idea that no one wants.

What about the Blockstream sidechains whitepaper?

Yes, that was a way to do it. The Drivechain hashrate escrow is a conceptually simpler way to achieve the same thing with improved incentives, less junk in the chain, more safety.

Isn't the hashrate escrow a very complex soft-fork?

Yes, but it is much simpler than SegWit. And, unlike SegWit, it doesn't force anything on users, i.e., it isn't a mandatory blocksize increase.

Why should we expect miners to care enough to participate in the voting mechanism?

Because it's in their own self-interest to do it, and it costs very little. Today over half of the miners mine RSK. It's not blind merged mining, it's a very convoluted process that requires them to run a RSK full node. For the Drivechain sidechains, an SPV node would be enough, or maybe just getting data from a block explorer API, so much much simpler.

What if I still don't like Drivechain even after reading this?

That is the entire point! You don't have to like it or use it as long as you're fine with other people using it. The hashrate escrow special addresses will not impact you at all, validation cost is minimal, and you get the benefit of people who want to use Drivechain migrating to their own sidechains and freeing up space for you in the mainchain. See also the point above about infighting.

See also

• Podcast episode with Ruben Somsen and Aaron van Wirdum explaining Drivechain
• Alternatives to Drivechain
• Drivechain comparison with Ethereum

@ fd78c37f:a0ec0833

In this edition, we’re thrilled to sit down with Tomek K from Bitcoin Alby, a passionate advocate for Bitcoin’s global adoption. Tomek K shares how Alby is driving innovation in the Bitcoin ecosystem and offers a glimpse into his vision for the cryptocurrency’s future. From his journey as a libertarian activist to co-founding the Bitcoin Film Festival, Tomek K’s story is one of curiosity, purpose, and a relentless pursuit of freedom through technology.

YakiHonne: Tomek K, it’s a pleasure to meet you! Today, we’re diving into your community topic—Alby Wallet. But before we begin, let me introduce our readers to Yakihonne. Yakihonne is a decentralized media client powered by the Nostr protocol, dedicated to promoting free speech through technology. It empowers creators to truly own their voices and assets, offering features like smart filtering, verified notes, and a focus on long-form content. So, Tomek, could you tell us about yourself and your work with Alby?

Tomek K: Of course! I’m Tomek K, originally from Poland, and right now, I’m speaking to you from Sri Lanka. I love traveling and observing how different countries adopt Bitcoin. For most of my career, I’ve been a free-market advocate, promoting economic freedom through various projects—essentially doing PR for capitalism. I’ve organized conferences, political demonstrations, economic seminars, summer festivals, and even opened a bar in Warsaw to spread these ideas in different ways.

During this advocacy work, I came across Bitcoin. At first, I didn’t pay much attention to it, but over time, I started feeling frustrated—our efforts raised awareness about freedom, but they didn’t bring measurable change. That led me to study Bitcoin more deeply, and I gradually shifted my focus to Bitcoin activism. Along the way, I collaborated with publishers to translate Bitcoin-related books into Polish and co-founded the Bitcoin Film Festival with friends from Meetup. Later, I joined Alby, marking my transition from free-market activism to Bitcoin promotion.

At the Bitcoin Film Festival, I handle operations and networking—organizing the event, managing logistics, and making things happen. Our team is small, but I enjoy the work. I’m passionate about Bitcoin because I came for the revolution, and I’m staying for the revolution.

That said, I don’t consider myself a Bitcoin absolutist. I see Bitcoin as a tool for freedom, not just a currency or a more efficient technology. If there were a better tool for advancing liberty and making societies freer, I’d probably focus on that. But for now, Bitcoin appears to be the most effective tool for freedom. Ultimately, I consider myself a “life maximalist”—because to live a good life, you need freedom, and to have freedom today, you need sound money. And right now, that money is Bitcoin.

YakiHonne: Was there a specific moment or event that sparked your interest in Bitcoin and motivated you to join the Alby community?

Tomek K: What attracted me to Bitcoin was its promise of global monetary independence and its ability to reduce the control of the Federal Reserve, central banks, and governments—the strongest and most covert control mechanisms in the world. Unfortunately, many people, even libertarians, often overlook this.

As for why I joined Alby, it’s because this startup is driven by values and mission rather than simply chasing profits, like selling tokens or games. This aligns well with my interest in the Lightning Network. As I explored Lightning more deeply, I came across Alby. I’ve always enjoyed testing new tools, trying them firsthand, and understanding the communities behind them—so naturally, I became part of it. Along the way, I also got to know some of the team members, which reinforced my involvement.

Additionally, Alby supported the Bitcoin Film Festival. While they weren’t the largest sponsor, their contribution was generous. The festival served as a great platform for them and other projects. I think it was good marketing because people like me—who have strong networking skills, arrange podcast interviews, and organize various activities—help build awareness and positive PR. That was part of my role.

If I had to pinpoint a single defining moment that led me here, I honestly couldn’t. Becoming a Bitcoiner doesn’t happen overnight. You can’t just read The Bitcoin Standard, declare that you understand Bitcoin, and instantly become a maximalist. Anyone who’s intellectually honest will admit that it takes multiple touchpoints—articles, films, career shifts, essays, hands-on experimentation, and actually using Bitcoin—to truly grasp its significance. I had many such moments along the way: reading The Bitcoin Standard, learning from friends who had a deeper understanding of Bitcoin, and working at Alby, which further expanded my knowledge of the Lightning Network’s capabilities and limitations. It wasn’t one turning point but a series of pivotal experiences that shaped my path.

YakiHonne: How did the Alby community start, and how did it attract its first members?

Tomek K: When I joined Alby, the community had already been established for some time. It originally emerged within the browser design community, where early users helped developers refine the product by providing feedback. That’s how the first members joined, and this process has been ongoing for four years now.

As for how Alby attracted members, it was through a mix of channels—social media (Twitter, Telegram, Discord), email engagement, and active participation in Bitcoin conferences. But the core strategy has always been openness, engaging with users, and listening to their feedback. Sometimes that means making a joke, sometimes defending against unfair criticism, and other times implementing requested features. We’ve always worked to maintain an active and friendly community atmosphere.

We also host bi-weekly community calls, which are a central part of our activities. Every two weeks, available team members meet with users for open Q&A sessions, issue discussions, and demonstrations of various projects integrating with Alby. I’ve participated in some of these calls, and they help maintain strong relationships with users, developers, and other projects—something crucial for the ecosystem. The Bitcoin technology landscape is somewhat fragmented, and grassroots coordination is necessary since there’s no single leader defining terminology or coding practices.

That’s also why Alby doesn’t exist in isolation. Almost everything we’ve built has been made possible by the creators of previous libraries, prior codebases, and collaborative efforts in writing specifications for protocols. Projects like Yakihonne and many others also recognize the importance of open-source collaboration. I think it’s essential to acknowledge the contributions of the open-source community. One thing I really appreciate is that Bitcoiners are driving open-source development in virtually every part of the world, all working toward a shared and meaningful goal.

YakiHonne:Were there any notable challenges in the early days that left a strong impression on you?

Tomek K :When I first joined Alby, I struggled with a bit of imposter syndrome for months. I was handling PR for the project, but I didn’t fully understand all the technical details—how certain protocols interact or what’s happening under the hood. It took time to get familiar with everything and really feel like I belonged.

Regulatory pressure has also been a huge challenge. In some cases, developers have been arrested, projects have had to leave certain countries, and users have been geoblocked based on their location. But challenges like these can also drive innovation. For example, Alby developed AlbyHub, an open-source self-custodial node, as a response to these kinds of issues.

There are always risks in this space—governments might suddenly demand a banking license or require compliance with new regulations. These are real obstacles, but we tackle them by embracing decentralization and open-source solutions. That’s how we ensure the project stays true to its mission and vision.

YakiHonne:If someone wanted to start a Bitcoin community today or grow an existing one, what advice would you give them?

Tomek K: The most important thing is to just get started. A community begins with action, and it takes more than one person. Even if it’s just you and a friend grabbing a beer, that’s already a start. Maybe after the first or second meetup, you post on Meetup.com, Twitter, or local forums:"Hey, we’re hosting a Bitcoin meetup in this city. We just want to connect with other Bitcoiners!" If you keep doing it consistently, the community will naturally grow. Over time, the bar where you meet might get interested in accepting Bitcoin, or you might meet some OGs in your area who decide to join—maybe they already run a business and want to support what you’re doing.

You don’t have to over-plan everything from the start. No need to think, “We need a podcast, 10 episodes, a logo…”—all that can come later. Just bootstrap it: organize a meetup, grab a beer, and get going. As you go, you’ll adapt, improve, and build recognition.Beyond that, it’s a great way to meet other Bitcoiners, develop leadership skills, and learn about community building. And at the very least, you’ll have fun doing it—which, honestly, is one of the main reasons I keep organizing meetups and other activities.

YakiHonne: Exactly, the key is to take action—just start and see where it leads. Does your community focus more on Bitcoin’s technical aspects, like coding and development, or do you emphasize non-technical areas such as education and outreach? Or do you try to balance both?

Tomek K: Our users come from all kinds of backgrounds. Some are very engaged and provide feedback regularly, while others prefer to stay in the background. Some attend our community calls, and within that group, some are developers actively building projects and collaborating with us. At the same time, there are developers we know are out there, but they never directly engage with us. That’s just how the Bitcoin community works—there’s no strict definition of being part of Alby. People engage in their own way. Some users are active on Discord, some aren’t, but we treat them all as part of the family, keeping them informed through newsletters, offering support, and making sure they stay updated with what’s happening at Alby.

As for whether we lean more toward technical development or non-technical outreach, there’s no clear-cut answer. Our community is diverse—we cater to a wide range of Lightning Network users. Some just use the browser extension, while others are deeply involved in our ecosystem. We also work with NGOs, educational initiatives, and community organizations. At the same time, we place a strong emphasis on developers and maintaining good relationships with them. Our repositories and developer portal offer useful libraries and examples, making it easier for both aspiring and experienced developers to integrate the Lightning Network into their projects. Developer relations are something we consider highly important.

YakiHonne: I understand that you're also the founder of another Bitcoin-related film project. Could you tell us a bit about it? What exactly inspired you to combine Bitcoin and filmmaking?

Tomek K: Yes, I founded Bitcoin Film Fest to help build what I call Bitcoin Cinema—an emerging industry that blends Bitcoin and filmmaking. I wanted to track everything happening at the intersection of these two worlds. Just like e-commerce, energy, and information technology, I believe the film industry will eventually be shaped by Bitcoin. And in fact, it’s already happening. There are Bitcoin-themed movies, and even major Hollywood productions have started including Bitcoin references. Bitcoin filmmakers, Bitcoin culture, and even a Bitcoin subculture already exist. We have our own heroes, stories, and values, and from this, films are being created. I love cinema, and I love Bitcoin—this was my way of bringing the two together.

The festival itself happened somewhat by accident—but maybe it was meant to be. It all started in Warsaw when I was organizing a Bitcoin meetup. I planned to screen a Bitcoin documentary, but due to technical issues, it didn’t happen. So, over a few beers, we came up with an idea: if we couldn’t show one film, why not go all in and create a full-scale Bitcoin film festival? We started researching and realized there were enough Bitcoin-related films out there to make it happen. So, we did.

The response from the community was overwhelmingly positive. It became clear that people wanted a space for Bitcoin cinema—a hub for information, networking, and collaboration. We started using the term “Binema” (Bitcoin Cinema) to describe this emerging genre. I find it fascinating to witness the growth of Bitcoin culture and storytelling. Before this, I had followed libertarian artistic movements closely, and now I see how important culture is for Bitcoin’s adoption—it’s not just about the technical and financial aspects.

Bitcoin adoption isn’t going to happen overnight, and it won’t happen without developers, educators, infrastructure builders, UX designers, and many others contributing to the ecosystem. Culture is one of the most powerful tools for shaping society, and I, like many others, am working to bring Bitcoin adoption closer through film. We’re witnessing the early days of Bitcoin cinema. I missed out on the birth of traditional cinema, but this time, I want to be part of it.

YakiHonne:In your region, does the government support or oppose Bitcoin? How has this stance impacted the development of the Bitcoin community so far?

Tomek K :Bitcoin doesn’t concern itself with nation-state borders, and frankly, we don’t either. The situation in Poland has little influence on what we do. The only connection is that I, along with two others, happen to be in Poland, but most of our team is globally distributed. On a broader scale, the U.S. tends to shape regulatory trends, and unfortunately, it often does so in a more restrictive way. However, Poland itself hasn’t had a significant impact on our work.

YakiHonne:Has your Bitcoin Film Fest community ever used film as a way to connect with members—perhaps by watching a Bitcoin-related movie or hosting a movie night to make things more fun and engaging? Have you done anything like that before?

Tomek K:Yes, absolutely! The film festival itself is a great example—we watch movies together and build a community around them. Aside from the festival we organized in Warsaw, we've also hosted film screenings at various Bitcoin events, like Sats and Facts in Thailand, BTC Prague, Plan B Lugano, Frimadera, Adopting Bitcoin, and several other conferences. We also organize online watch parties—actually, there's one happening next Sunday. The movie is available on Prime Video, but we'll sync up on Discord to watch it together, chat, and share our thoughts. We'll be announcing it on Twitter, so if you check Bitcoin Film Fest on Twitter, you'll find details on how to join.

Film has been a great way to connect with members and spark discussions. We've seen Bitcoin meetups worldwide organizing movie nights—our volunteer friends in Montenegro have hosted one, and our partners in Kenya and South Africa have done the same. Lately, movie nights have been happening more and more frequently, which is exciting.

It's still early—after all, Bitcoin is only 16 years old, so the selection of Bitcoin movies is still relatively small. Many of these films haven’t had large budgets or massive talent pools yet, but that’s changing. Right now, we’re primarily focused on showing films within the Bitcoin community rather than creating films aimed at the general public. That said, those kinds of projects are also emerging. I’m optimistic about the growth of Bitcoin cinema—better storytelling, AI-driven advancements, increasing interest from audiences, and even sponsors willing to invest in filmmakers. Big things are coming, and while we already have some great Bitcoin films, the best is yet to come. We’re still in the early days, and this is the time to contribute and help shape the future of Bitcoin cinema.

YakiHonne:We’ve come to the end of today’s interview, and I’ve truly enjoyed every moment of it. I’m very sure your idea will be incredibly engaging, inspiring more people and attracting a broad audience. Thank you so much for your time today—it was a great conversation.

@ 3bf0c63f:aefa459d

A Lightning penalty transaction

It was a cold day and I remembered that this lightningd node I was running on my local desktop to work on poncho actually had mainnet channels in it. Two channels, both private, bought on https://lnbig.com/ a while ago when I was trying to conduct an anonymous griefing attack on big nodes of the network just to prove it was possible (the attempts proved unsuccessful after some hours and I gave up).

It is always painful to close channels because paying fees hurts me psychologically, and then it hurts even more to be left with a new small UTXO that will had to be spent to somewhere but that can barely pay for itself, but it also didn't make sense to just leave the channels there and risk forgetting them and losing them forever, so I had to do something.

One of the channels had 0 satoshis on my side, so that was easy. Mutually closed and I don't have to think anymore about it.

The other one had 10145 satoshis on my side -- out of a total of 100000 satoshis. Why can't I take my part all over over Lightning and leave the full channel UTXO to LNBIG? I wish I could do that, I don't want a small UTXO. I was not sure about it, but if the penalty reserve was 1% maybe I could take out abou 9000 satoshis and then close it with 1000 on my side? But then what would I do with this 1000 sat UTXO that would remain? Can't I donate it to miners or something?

I was in the middle of this thoughts stream when it came to me the idea of causing a penalty transaction to give those abundant 1000 sat to Mr. LNBIG as a donation for his excellent services to the network and the cause of Bitcoin, and for having supported the development of https://sbw.app/ and the hosted channels protocol.

Unfortunately lightningd doesn't have a command triggerpenaltytransaction or trytostealusingoldstate, so what I did was:

First I stopped lightningd then copied the database to elsewhere: cp ~/.lightningd/bitcoin/lightningd.sqlite3 ~/.lightning/bitcoin/lightningd.sqlite3.bak then I restarted lightningd and fighted against the way-too-aggressive MPP splitting algorithm the pay command uses to pay invoices, but finally managed to pull about 9000 satoshis to my Z Bot that lives on the terrible (but still infinitely better than Twitter DMs) "webk" flavor of the Telegram web application and which is linked to my against-bitcoin-ethos-country-censoring ZEBEDEE Wallet. The operation wasn't smooth but it didn't take more than 10 invoices and pay commands.

With the money out and safe elsewhere, I stopped the node again, moved the database back with a reckless mv ~/.lightning/bitcoin/lightningd.sqlite3.bak ~/.lightningd/bitcoin/lightningd.sqlite3 and restarted it, but to prevent my lightningd from being super naïve and telling LNBIG that it had an old state (I don't know if this would happen) which would cause LNBIG to close the channel in a boring way, I used the --offline flag which apparently causes the node to not do any external connections.

Finally I checked my balance using lightning-cli listfunds and there it was, again, the 10145 satoshis I had at the start! A fantastic money creation trick, comparable to the ones central banks execute daily.

I was ready to close the channel now, but the lightning-cli close command had an option for specifying how many seconds I would wait for a mutual close before proceeding to a unilateral close. There is no forceclose command like Éclair hasor anything like that. I was afraid that even if I gave LNBIG one second it would try to do boring things, so I paused to consider how could I just broadcast the commitment transaction manually, looked inside the SQLite database and the channels table with its millions of columns with cryptic names in the unbearable .schema output, imagined that lightningd maybe wouldn't know how to proceed to take the money from the to-local output if I managed to broadcast it manually (and in the unlikely event that LNBIG wouldn't broadcast the penalty transaction), so I decided to just accept the risk and call lightning-cli close 706327x1588x0 1

But it went well. The --offline flag apparently really works, as it just considered LNBIG to be offline and 1 second later I got the desired result.

My happiness was complete when I saw the commitment transaction with my output for 10145 satoshis published on the central database of Bitcoin, blockstream.info.

Then I went to eat something and it seems LNBIG wasn't offline or sleeping, he was certainly looking at all the logs from his 274 nodes in a big room full of monitors, very alert and eating an apple while drinking coffee, ready to take action, for when I came back, minutes later, I could see it, again on the single source of truth for the Bitcoin blockchain, the Blockstream explorer. I've refreshed the page and there it was, a small blue link right inside the little box that showed my to-local output, a notice saying it had been spent -- not by my lightningd since that would have to wait 9000 blocks, but by the same transaction that spent the other output, from which I could be very sure it was it, the glorious, mighty, unforgiving penalty transaction, splitting the earth, showing itself in all its power, and taking my 10145 satoshis to their rightful owner.

@ 3bf0c63f:aefa459d

nostr - Notes and Other Stuff Transmitted by Relays

The simplest open protocol that is able to create a censorship-resistant global "social" network once and for all.

It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works.

Very short summary of how it works, if you don't plan to read anything else:

Everybody runs a client. It can be a native client, a web client, etc. To publish something, you write a post, sign it with your key and send it to multiple relays (servers hosted by someone else, or yourself). To get updates from other people, you ask multiple relays if they know anything about these other people. Anyone can run a relay. A relay is very simple and dumb. It does nothing besides accepting posts from some people and forwarding to others. Relays don't have to be trusted. Signatures are verified on the client side.

This is needed because other solutions are broken:

The problem with Twitter

• Twitter has ads;
• Twitter uses bizarre techniques to keep you addicted;
• Twitter doesn't show an actual historical feed from people you follow;
• Twitter bans people;
• Twitter shadowbans people.
• Twitter has a lot of spam.

The problem with Mastodon and similar programs

• User identities are attached to domain names controlled by third-parties;
• Server owners can ban you, just like Twitter; Server owners can also block other servers;
• Migration between servers is an afterthought and can only be accomplished if servers cooperate. It doesn't work in an adversarial environment (all followers are lost);
• There are no clear incentives to run servers, therefore they tend to be run by enthusiasts and people who want to have their name attached to a cool domain. Then, users are subject to the despotism of a single person, which is often worse than that of a big company like Twitter, and they can't migrate out;
• Since servers tend to be run amateurishly, they are often abandoned after a while — which is effectively the same as banning everybody;
• It doesn't make sense to have a ton of servers if updates from every server will have to be painfully pushed (and saved!) to a ton of other servers. This point is exacerbated by the fact that servers tend to exist in huge numbers, therefore more data has to be passed to more places more often;
• For the specific example of video sharing, ActivityPub enthusiasts realized it would be completely impossible to transmit video from server to server the way text notes are, so they decided to keep the video hosted only from the single instance where it was posted to, which is similar to the Nostr approach.

The problem with SSB (Secure Scuttlebutt)

• It doesn't have many problems. I think it's great. In fact, I was going to use it as a basis for this, but
• its protocol is too complicated because it wasn't thought about being an open protocol at all. It was just written in JavaScript in probably a quick way to solve a specific problem and grew from that, therefore it has weird and unnecessary quirks like signing a JSON string which must strictly follow the rules of ECMA-262 6th Edition;
• It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason);
• It is not as simple as Nostr, as it was primarily made for P2P syncing, with "pubs" being an afterthought;
• Still, it may be worth considering using SSB instead of this custom protocol and just adapting it to the client-relay server model, because reusing a standard is always better than trying to get people in a new one.

The problem with other solutions that require everybody to run their own server

• They require everybody to run their own server;
• Sometimes people can still be censored in these because domain names can be censored.

How does Nostr work?

• There are two components: clients and relays. Each user runs a client. Anyone can run a relay.
• Every user is identified by a public key. Every post is signed. Every client validates these signatures.
• Clients fetch data from relays of their choice and publish data to other relays of their choice. A relay doesn't talk to another relay, only directly to users.
• For example, to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.
• On startup, a client queries data from all relays it knows for all users it follows (for example, all updates from the last day), then displays that data to the user chronologically.
• A "post" can contain any kind of structured data, but the most used ones are going to find their way into the standard so all clients and relays can handle them seamlessly.

How does it solve the problems the networks above can't?

• Users getting banned and servers being closed
• A relay can block a user from publishing anything there, but that has no effect on them as they can still publish to other relays. Since users are identified by a public key, they don't lose their identities and their follower base when they get banned.
• Instead of requiring users to manually type new relay addresses (although this should also be supported), whenever someone you're following posts a server recommendation, the client should automatically add that to the list of relays it will query.
• If someone is using a relay to publish their data but wants to migrate to another one, they can publish a server recommendation to that previous relay and go;
• If someone gets banned from many relays such that they can't get their server recommendations broadcasted, they may still let some close friends know through other means with which relay they are publishing now. Then, these close friends can publish server recommendations to that new server, and slowly, the old follower base of the banned user will begin finding their posts again from the new relay.

• All of the above is valid too for when a relay ceases its operations.

• Censorship-resistance

• Each user can publish their updates to any number of relays.

• A relay can charge a fee (the negotiation of that fee is outside of the protocol for now) from users to publish there, which ensures censorship-resistance (there will always be some Russian server willing to take your money in exchange for serving your posts).

• Spam

• If spam is a concern for a relay, it can require payment for publication or some other form of authentication, such as an email address or phone, and associate these internally with a pubkey that then gets to publish to that relay — or other anti-spam techniques, like hashcash or captchas. If a relay is being used as a spam vector, it can easily be unlisted by clients, which can continue to fetch updates from other relays.

• Data storage

• For the network to stay healthy, there is no need for hundreds of active relays. In fact, it can work just fine with just a handful, given the fact that new relays can be created and spread through the network easily in case the existing relays start misbehaving. Therefore, the amount of data storage required, in general, is relatively less than Mastodon or similar software.

• Or considering a different outcome: one in which there exist hundreds of niche relays run by amateurs, each relaying updates from a small group of users. The architecture scales just as well: data is sent from users to a single server, and from that server directly to the users who will consume that. It doesn't have to be stored by anyone else. In this situation, it is not a big burden for any single server to process updates from others, and having amateur servers is not a problem.

• Video and other heavy content

• It's easy for a relay to reject large content, or to charge for accepting and hosting large content. When information and incentives are clear, it's easy for the market forces to solve the problem.

• Techniques to trick the user

• Each client can decide how to best show posts to users, so there is always the option of just consuming what you want in the manner you want — from using an AI to decide the order of the updates you'll see to just reading them in chronological order.

FAQ

• This is very simple. Why hasn't anyone done it before?

I don't know, but I imagine it has to do with the fact that people making social networks are either companies wanting to make money or P2P activists who want to make a thing completely without servers. They both fail to see the specific mix of both worlds that Nostr uses.

• How do I find people to follow?

First, you must know them and get their public key somehow, either by asking or by seeing it referenced somewhere. Once you're inside a Nostr social network you'll be able to see them interacting with other people and then you can also start following and interacting with these others.

• How do I find relays? What happens if I'm not connected to the same relays someone else is?

You won't be able to communicate with that person. But there are hints on events that can be used so that your client software (or you, manually) knows how to connect to the other person's relay and interact with them. There are other ideas on how to solve this too in the future but we can't ever promise perfect reachability, no protocol can.

• Can I know how many people are following me?

No, but you can get some estimates if relays cooperate in an extra-protocol way.

• What incentive is there for people to run relays?

The question is misleading. It assumes that relays are free dumb pipes that exist such that people can move data around through them. In this case yes, the incentives would not exist. This in fact could be said of DHT nodes in all other p2p network stacks: what incentive is there for people to run DHT nodes?

• Nostr enables you to move between server relays or use multiple relays but if these relays are just on AWS or Azure what’s the difference?

There are literally thousands of VPS providers scattered all around the globe today, there is not only AWS or Azure. AWS or Azure are exactly the providers used by single centralized service providers that need a lot of scale, and even then not just these two. For smaller relay servers any VPS will do the job very well.

@ 3bf0c63f:aefa459d

jiq-web

Made with jq-web, a tool to explore JSON using jq that works like jiq.

• https://jq.alhur.es/jiq/
• https://github.com/fiatjaf/jiq-web

See also

• jq-finder

@ 91bea5cd:1df4451c

O Contexto Legal Brasileiro e o Consentimento

No ordenamento jurídico brasileiro, o consentimento do ofendido pode, em certas circunstâncias, afastar a ilicitude de um ato que, sem ele, configuraria crime (como lesão corporal leve, prevista no Art. 129 do Código Penal). Contudo, o consentimento tem limites claros: não é válido para bens jurídicos indisponíveis, como a vida, e sua eficácia é questionável em casos de lesões corporais graves ou gravíssimas.

A prática de BDSM consensual situa-se em uma zona complexa. Em tese, se ambos os parceiros são adultos, capazes, e consentiram livre e informadamente nos atos praticados, sem que resultem em lesões graves permanentes ou risco de morte não consentido, não haveria crime. O desafio reside na comprovação desse consentimento, especialmente se uma das partes, posteriormente, o negar ou alegar coação.

A Lei Maria da Penha (Lei nº 11.340/2006)

A Lei Maria da Penha é um marco fundamental na proteção da mulher contra a violência doméstica e familiar. Ela estabelece mecanismos para coibir e prevenir tal violência, definindo suas formas (física, psicológica, sexual, patrimonial e moral) e prevendo medidas protetivas de urgência.

Embora essencial, a aplicação da lei em contextos de BDSM pode ser delicada. Uma alegação de violência por parte da mulher, mesmo que as lesões ou situações decorram de práticas consensuais, tende a receber atenção prioritária das autoridades, dada a presunção de vulnerabilidade estabelecida pela lei. Isso pode criar um cenário onde o parceiro masculino enfrenta dificuldades significativas em demonstrar a natureza consensual dos atos, especialmente se não houver provas robustas pré-constituídas.

Outros riscos:

Lesão corporal grave ou gravíssima (art. 129, §§ 1º e 2º, CP), não pode ser justificada pelo consentimento, podendo ensejar persecução penal.

Crimes contra a dignidade sexual (arts. 213 e seguintes do CP) são de ação pública incondicionada e independem de representação da vítima para a investigação e denúncia.

Riscos de Falsas Acusações e Alegação de Coação Futura

Os riscos para os praticantes de BDSM, especialmente para o parceiro que assume o papel dominante ou que inflige dor/restrição (frequentemente, mas não exclusivamente, o homem), podem surgir de diversas frentes:

1. Acusações Externas: Vizinhos, familiares ou amigos que desconhecem a natureza consensual do relacionamento podem interpretar sons, marcas ou comportamentos como sinais de abuso e denunciar às autoridades.
2. Alegações Futuras da Parceira: Em caso de término conturbado, vingança, arrependimento ou mudança de perspectiva, a parceira pode reinterpretar as práticas passadas como abuso e buscar reparação ou retaliação através de uma denúncia. A alegação pode ser de que o consentimento nunca existiu ou foi viciado.
3. Alegação de Coação: Uma das formas mais complexas de refutar é a alegação de que o consentimento foi obtido mediante coação (física, moral, psicológica ou econômica). A parceira pode alegar, por exemplo, que se sentia pressionada, intimidada ou dependente, e que seu "sim" não era genuíno. Provar a ausência de coação a posteriori é extremamente difícil.
4. Ingenuidade e Vulnerabilidade Masculina: Muitos homens, confiando na dinâmica consensual e na parceira, podem negligenciar a necessidade de precauções. A crença de que "isso nunca aconteceria comigo" ou a falta de conhecimento sobre as implicações legais e o peso processual de uma acusação no âmbito da Lei Maria da Penha podem deixá-los vulneráveis. A presença de marcas físicas, mesmo que consentidas, pode ser usada como evidência de agressão, invertendo o ônus da prova na prática, ainda que não na teoria jurídica.

Estratégias de Prevenção e Mitigação

Não existe um método infalível para evitar completamente o risco de uma falsa acusação, mas diversas medidas podem ser adotadas para construir um histórico de consentimento e reduzir vulnerabilidades:

1. Comunicação Explícita e Contínua: A base de qualquer prática BDSM segura é a comunicação constante. Negociar limites, desejos, palavras de segurança ("safewords") e expectativas antes, durante e depois das cenas é crucial. Manter registros dessas negociações (e-mails, mensagens, diários compartilhados) pode ser útil.

2. Documentação do Consentimento:

   • Contratos de Relacionamento/Cena: Embora a validade jurídica de "contratos BDSM" seja discutível no Brasil (não podem afastar normas de ordem pública), eles servem como forte evidência da intenção das partes, da negociação detalhada de limites e do consentimento informado. Devem ser claros, datados, assinados e, idealmente, reconhecidos em cartório (para prova de data e autenticidade das assinaturas).

   • Registros Audiovisuais: Gravar (com consentimento explícito para a gravação) discussões sobre consentimento e limites antes das cenas pode ser uma prova poderosa. Gravar as próprias cenas é mais complexo devido a questões de privacidade e potencial uso indevido, mas pode ser considerado em casos específicos, sempre com consentimento mútuo documentado para a gravação.

     Importante: a gravação deve ser com ciência da outra parte, para não configurar violação da intimidade (art. 5º, X, da Constituição Federal e art. 20 do Código Civil).

3. Testemunhas: Em alguns contextos de comunidade BDSM, a presença de terceiros de confiança durante negociações ou mesmo cenas pode servir como testemunho, embora isso possa alterar a dinâmica íntima do casal.

4. Estabelecimento Claro de Limites e Palavras de Segurança: Definir e respeitar rigorosamente os limites (o que é permitido, o que é proibido) e as palavras de segurança é fundamental. O desrespeito a uma palavra de segurança encerra o consentimento para aquele ato.
5. Avaliação Contínua do Consentimento: O consentimento não é um cheque em branco; ele deve ser entusiástico, contínuo e revogável a qualquer momento. Verificar o bem-estar do parceiro durante a cena ("check-ins") é essencial.
6. Discrição e Cuidado com Evidências Físicas: Ser discreto sobre a natureza do relacionamento pode evitar mal-entendidos externos. Após cenas que deixem marcas, é prudente que ambos os parceiros estejam cientes e de acordo, talvez documentando por fotos (com data) e uma nota sobre a consensualidade da prática que as gerou.
7. Aconselhamento Jurídico Preventivo: Consultar um advogado especializado em direito de família e criminal, com sensibilidade para dinâmicas de relacionamento alternativas, pode fornecer orientação personalizada sobre as melhores formas de documentar o consentimento e entender os riscos legais específicos.

Observações Importantes

• Nenhuma documentação substitui a necessidade de consentimento real, livre, informado e contínuo.
• A lei brasileira protege a "integridade física" e a "dignidade humana". Práticas que resultem em lesões graves ou que violem a dignidade de forma não consentida (ou com consentimento viciado) serão ilegais, independentemente de qualquer acordo prévio.
• Em caso de acusação, a existência de documentação robusta de consentimento não garante a absolvição, mas fortalece significativamente a defesa, ajudando a demonstrar a natureza consensual da relação e das práticas.

• A alegação de coação futura é particularmente difícil de prevenir apenas com documentos. Um histórico consistente de comunicação aberta (whatsapp/telegram/e-mails), respeito mútuo e ausência de dependência ou controle excessivo na relação pode ajudar a contextualizar a dinâmica como não coercitiva.

• Cuidado com Marcas Visíveis e Lesões Graves Práticas que resultam em hematomas severos ou lesões podem ser interpretadas como agressão, mesmo que consentidas. Evitar excessos protege não apenas a integridade física, mas também evita questionamentos legais futuros.

O que vem a ser consentimento viciado

No Direito, consentimento viciado é quando a pessoa concorda com algo, mas a vontade dela não é livre ou plena — ou seja, o consentimento existe formalmente, mas é defeituoso por alguma razão.

O Código Civil brasileiro (art. 138 a 165) define várias formas de vício de consentimento. As principais são:

Erro: A pessoa se engana sobre o que está consentindo. (Ex.: A pessoa acredita que vai participar de um jogo leve, mas na verdade é exposta a práticas pesadas.)

Dolo: A pessoa é enganada propositalmente para aceitar algo. (Ex.: Alguém mente sobre o que vai acontecer durante a prática.)

Coação: A pessoa é forçada ou ameaçada a consentir. (Ex.: "Se você não aceitar, eu termino com você" — pressão emocional forte pode ser vista como coação.)

Estado de perigo ou lesão: A pessoa aceita algo em situação de necessidade extrema ou abuso de sua vulnerabilidade. (Ex.: Alguém em situação emocional muito fragilizada é induzida a aceitar práticas que normalmente recusaria.)

No contexto de BDSM, isso é ainda mais delicado: Mesmo que a pessoa tenha "assinado" um contrato ou dito "sim", se depois ela alegar que seu consentimento foi dado sob medo, engano ou pressão psicológica, o consentimento pode ser considerado viciado — e, portanto, juridicamente inválido.

Isso tem duas implicações sérias:

1. O crime não se descaracteriza: Se houver vício, o consentimento é ignorado e a prática pode ser tratada como crime normal (lesão corporal, estupro, tortura, etc.).

2. A prova do consentimento precisa ser sólida: Mostrando que a pessoa estava informada, lúcida, livre e sem qualquer tipo de coação.

   Consentimento viciado é quando a pessoa concorda formalmente, mas de maneira enganada, forçada ou pressionada, tornando o consentimento inútil para efeitos jurídicos.

Conclusão

Casais que praticam BDSM consensual no Brasil navegam em um terreno que exige não apenas confiança mútua e comunicação excepcional, mas também uma consciência aguçada das complexidades legais e dos riscos de interpretações equivocadas ou acusações mal-intencionadas. Embora o BDSM seja uma expressão legítima da sexualidade humana, sua prática no Brasil exige responsabilidade redobrada. Ter provas claras de consentimento, manter a comunicação aberta e agir com prudência são formas eficazes de se proteger de falsas alegações e preservar a liberdade e a segurança de todos os envolvidos. Embora leis controversas como a Maria da Penha sejam "vitais" para a proteção contra a violência real, os praticantes de BDSM, e em particular os homens nesse contexto, devem adotar uma postura proativa e prudente para mitigar os riscos inerentes à potencial má interpretação ou instrumentalização dessas práticas e leis, garantindo que a expressão de sua consensualidade esteja resguardada na medida do possível.

---

Importante: No Brasil, mesmo com tudo isso, o Ministério Público pode denunciar por crime como lesão corporal grave, estupro ou tortura, independente de consentimento. Então a prudência nas práticas é fundamental.

Aviso Legal: Este artigo tem caráter meramente informativo e não constitui aconselhamento jurídico. As leis e interpretações podem mudar, e cada situação é única. Recomenda-se buscar orientação de um advogado qualificado para discutir casos específicos.

Se curtiu este artigo faça uma contribuição, se tiver algum ponto relevante para o artigo deixe seu comentário.

@ 3bf0c63f:aefa459d

The unit test bubble

Look at the following piece of Go code:

func NewQuery(query []rune) *Query { q := &Query{ query: &[]rune{}, complete: &[]rune{}, } _ = q.Set(query) return q } func NewQueryWithString(query string) *Query { return NewQuery([]rune(query)) }

It is taken from a GitHub project with over 2000 stars.

Now take a look at these unit tests for the same package:

``` func TestNewQuery(t *testing.T) { var assert = assert.New(t)

v := []rune(".name")
q := NewQuery(v)

assert.Equal(*q.query, []rune(".name"))
assert.Equal(*q.complete, []rune(""))

}

func TestNewQueryWithString(t *testing.T) { var assert = assert.New(t)

q := NewQueryWithString(".name")

assert.Equal(*q.query, []rune(".name"))
assert.Equal(*q.complete, []rune(""))

} ```

Now be honest: what are these for? Is this part of an attack to eat all GitHub storage and head them to bankruptcy?

Also

• my personal approach on using let, const and var in javascript

@ 3bf0c63f:aefa459d

A estrutura lógica do livro didático

Todos os livros didáticos e cursos expõem seus conteúdos a partir de uma organização lógica prévia, um esquema de todo o conteúdo que julgam relevante, tudo muito organizadinho em tópicos e subtópicos segundo a ordem lógica que mais se aproxima da ordem natural das coisas. Imagine um sumário de um manual ou livro didático.

A minha experiência é a de que esse método serve muito bem para ninguém entender nada. A organização lógica perfeita de um campo de conhecimento é o resultado final de um estudo, não o seu início. As pessoas que escrevem esses manuais e dão esses cursos, mesmo quando sabem do que estão falando (um acontecimento aparentemente raro), o fazem a partir do seu próprio ponto de vista, atingido após uma vida de dedicação ao assunto (ou então copiando outros manuais e livros didáticos, o que eu chutaria que é o método mais comum).

Para o neófito, a melhor maneira de entender algo é através de imersões em micro-tópicos, sem muita noção da posição daquele tópico na hierarquia geral da ciência.

• Revista Educativa, um exemplo de como não ensinar nada às crianças.
• Zettelkasten, a ordem surgindo do caos, ao invés de temas se encaixando numa ordem preexistentes.

@ 3bf0c63f:aefa459d

Boardthreads

This was a very badly done service for turning a Trello list into a helpdesk UI.

Surprisingly, it had more paying users than Websites For Trello, which I was working on simultaneously and dedicating much more time to it.

The Neo4j database I used for this was a very poor choice, it was probably the cause of all the bugs.

-https://github.com/fiatjaf/boardthreads

@ 3bf0c63f:aefa459d

Ryan Fugger's Ripple

Before XRP, the shitcoin, bought it, "Ripple" was used by Ryan Fugger as the name for his project to create a peer-to-peer network of trust channels for money transfer. The basic idea is that Alice trusts Bob personally, Bob trusts Carol personally and Carol trusts David personally, therefore it is possible for Alice to send a payment to David by creating debt across A--B, B--C and C--D. Later either payments in the opposite direction (not necessarily from David to Alice, as the network can have trust relationships to multiple other peers in a complex graph) would maybe clear that debt (or not), but ultimately Bob would expect Alice to pay him in kind to settle the debt, Carol would expect Bob to pay her in kind and David would expect Carol to pay him in kind.

The system above works quite well inside a centralized trusted platform like Fugger's own Ripplepay website (even when it was supposed to be just proof-of-concept, it ended up being actually used to facilitate payments across small communities), but that cannot scale as participants would all rely on it and ultimately have to blindly trust that platform.[^trust-ripplepay]

If a truly peer-to-peer system could be designed, it would have a chance of scaling across the entire society and the ability to enable truly open payments over the internet, an unreachable goal unless you use either a credit card provider, which is bureaucratic, unsafe, expensive, taxable, not private at all and cumbersome -- or Bitcoin, which is awesome and excel in all aspects except scalability for day-to-day transactions.

The protocol can take many forms, but essentially it goes like this: 1. A finds a route (A--B--C--D) between her and D somehow; 2. A "prepares" a payment to B, tells B to do the same with C and so on (to prepare means to give B a conditional IOU that will be valid as long as the full payment completes); 3. When the chain of prepared messages reaches D, D somehow "commits" the payment. 4. After the commit, A now really does owe B and so on, and D really knows it has been effectively paid by A (in the form of debt from C) so it can ship goods to A.

The step 3 is the point in which the problem of the decentralized commit arises.

Fugger and the original Ripple community failed to solve the problem of the decentralized commit, which is required for such a system to be deployed. Not to blame them, as they've recognized the problem (unlike other people that had the same idea later[^clueless-people]) and documented many sub-optimal solutions[^decentralized-commit].

No one thinks about it in these terms, but the Bitcoin Lightning Network is itself a Ripple-like system with an embedded solution to the problem of the decentralized commit.

[^trust-ripplepay]: You may ask why is it bad to trust a central point if all this is already based on trust relationships between peers. If the platform goes malicious peers can jump out and resolve things on their own! But that's not so simple, it's not obvious when the platform will be malicious or not, it's not clear what to do if the platform deletes data or change history. Ultimately it cannot scale because even if it was very trustworthy you wouldn't want the entire global economy resting upon Ryan Fugger's webserver, nor does he want that. [^clueless-people]: See, for example, LedgerLoops, Offst and Settle. [^decentralized-commit]: The old Ripple wiki lists the "registry commit method" (which requires trust in a third-party), the "bare commit method" (which is not an atomic commit) and the "blockchain commit method" (which publishes transactions to the Bitcoin blockchain and so does not scale.

@ 75869cfa:76819987

GM, Nostriches!

The Nostr Review is a biweekly newsletter focused on Nostr statistics, protocol updates, exciting programs, the long-form content ecosystem, and key events happening in the Nostr-verse. If you’re interested, join me in covering updates from the Nostr ecosystem!

Quick review:

In the past two weeks, Nostr statistics indicate over 225,000 daily trusted pubkey events. The number of new users has seen a notable decrease, with profiles containing a contact list dropping by 95%. More than 10 million events have been published, with posts and reposts showing a decrease. Total Zap activity stands at approximately 15 million, marking a 10% decrease.

Additionally, 26 pull requests were submitted to the Nostr protocol, with 6 merged. A total of 45 Nostr projects were tracked, with 8 releasing product updates, and over 463 long-form articles were published, 29% focusing on Bitcoin and Nostr. During this period, 2 notable events took place, and 3 significant events are upcoming.

Nostr Statistics

Based on user activity, the total daily trusted pubkeys writing events is about 225,000, representing a slight 8 % decrease compared to the previous period. Daily activity peaked at 18179 events, with a low of approximately 16093.

The number of new users has decreased significantly. Profiles with a contact list are now around 17,511, reflecting a 95% drop. Profiles with a bio have decreased by 62% compared to the previous period. The only category showing growth is pubkeys writing events, which have increased by 27%.

Regarding event publishing, all metrics have shown a decline. The total number of note events published is around 10 million, reflecting a 14% decrease. Posts remain the most dominant in terms of volume, totaling approximately 1.6 million, which is a 6.1% decrease. Both reposts and reactions have decreased by about 10%.

For zap activity, the total zap amount is about 15 million, showing an increase of over 10% compared to the previous period.

Data source: https://stats.nostr.band/

NIPs

Bulletin Boards

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z is proposing that A bulletin board is a relay-centric system of forums where users can post and reply to others, typically around a specific community. The relay operator controls and moderates who can post and view content. A board is defined by kind:30890. Its naddr representation must provide the community's home relays, from which all posts should be gathered. No other relays should be used.

Add NIP-101e: Workout Events

nostr:npub1xy54p83r6wnpyhs52xjeztd7qyyeu9ghymz8v66yu8kt3jzx75rqhf3urc is proposing a standardized way to represent fitness and workout data in Nostr, including: Exercise Templates (kind: 33401) for storing reusable exercise definitions, Workout Templates (kind: 33402) for defining workout plans, Workout Records (kind: 1301) for recording completed workouts. The format provides structured data for fitness tracking while following Nostr conventions for data representation.Many fitness applications use proprietary formats, locking user data into specific platforms. This NIP enables decentralized fitness tracking, allowing users to control their workout data and history while facilitating social sharing and integration between fitness applications.

NIP-47 client-created secret

nostr:npub1zk6u7mxlflguqteghn8q7xtu47hyerruv6379c36l8lxzzr4x90q0gl6ef is proposing a PR introduces two "1-click" connection flows for setting up initial NWC connections. Rather than having to copy-paste a connection string, the user is presented with an authorization page which they can approve or decline. The secret is generated locally and never leaves the client. HTTP flow - for publicly accessible lightning wallets. Implemented in Alby Hub (my.albyhub.com) and CoinOS (coinos.io). Nostr flow - for mobile-based / self-hosted lightning wallets, very similar to NWA but without a new event type added. Implemented in Alby Go and Alby Hub. Benefits over NWC Deep Links are that it works cross-device, mobile to web, and the client-generated secret never leaves the client. Both flows are also implemented in Alby JS SDK and Bitcoin Connect.

add B0 NIP for Blossom interaction

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 describes a tiny subset of possible Blossom capabilities, but arguably the most important from the point of view of a most basic Nostr client. This NIP specifies how Nostr clients can use Blossom for handling media. Blossom is a set of standards (called BUDs) for dealing with servers that store files addressable by their SHA-256 sums. Nostr clients may make use of all the BUDs for allowing users to upload files, manage their own files and so on, but most importantly Nostr clients SHOULD make use of BUD-03 to fetch kind:10063 lists of servers for each user.

NIP-C0: Communi-keys

nostr:npub149p5act9a5qm9p47elp8w8h3wpwn2d7s2xecw2ygnrxqp4wgsklq9g722q defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays, introducing the concept of "Communi-keys". This approach allows any existing npub to become a community (identity + manager) while maintaining compatibility with existing relay infrastructure.

A way for relays to be honest about their algos

securitybrahh is proposing a PR introduces NIP-41, a way for relays to be honest about their algos, edits 01.md to account for changes in limit (related #78, #1434, received_at?, #620, #1645) when algo is provided, appends 11.md for relays to advertize whether they are an aggregator or not and their provided algos. solves #522, supersedes #579.

nip31: template-based "alt" tags for known kinds

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 is proposing that clients hardcoding alt tags are not very trustworthy. alt tags tend to be garbage in a long-enough timeframe.This fixes it with hardcoded rich templates that anyone can implement very easily without having to do it manually for each kind. alt tags can still be used as a fallback.

First draft of NIP-44v3

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z is proposing a PR addresses 3 main problems of NIP-44v2. First, It has a message size limit of 65Kb, which is unnecessarily small. Second, It forces the encrypting key to be the same as the event's signing key. Which forces multi-sig actors to share their main private key in order to encrypt the payload that would be later signed by the group. Decoupling singing and encryption keys, for both source and destination, is one of the goals of this version. And It offers no way to describe what's inside the encrypted blob before requesting the user's approval to decrypt and send the decrypted info back to the requesting application. This PR adds an alt description to allow decrypting signers to display a message and warn the user of what type of information the requesting application is receiving.

Notable Projects

Damus nostr:npub18m76awca3y37hkvuneavuw6pjj4525fw90necxmadrvjg0sdy6qsngq955

• Notes in progress will always be persisted and saved automatically. Never lose those banger notes when you aren't quite ready to ship them.
• Make your profile look just right without any fuss. It also optimizes them on upload now to not nuke other people’s phone data bills.
• You won't see the same note more than once in your home feed.
• Fixed note loading when clicking notifications and damus.io links.
• Fixed NWC not working when you first connect a wallet.
• Fixed overly sensitive and mildly infuriating touch gestures in the thread view when scrolling

Primal nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg

Primal for Android build 2.1.9 has been released. * Multi-account support * Deep linking support * "Share via Primal" support * Bug fixes and improvements

Yakihonne nostr:npub1yzvxlwp7wawed5vgefwfmugvumtp8c8t0etk3g8sky4n0ndvyxesnxrf8q

YakiHonne Wallet just got a fresh new look!

0xchat nostr:npub1tm99pgz2lth724jeld6gzz6zv48zy6xp4n9xu5uqrwvx9km54qaqkkxn72

0xchat v1.4.7-beta release * Upgraded the Flutter framework to v3.29.0. * Private chat implementation changed to NIP-104 Nostr MLS. * NIP-17 and NIP-29 messages now support q tags. * You can swipe left to reply to your own messages. * Chat messages now support code block display. * Copy images from the clipboard. * Fixed an issue where underlined text in chat appeared as italic.

GOSSIP 0.14.0 nostr:npub189j8y280mhezlp98ecmdzydn0r8970g4hpqpx3u9tcztynywfczqqr3tg8

Several major bugs have been fixed in the last week. * New Features and Improvements * Zappers and amounts are now shown (click on the zap total) * Reactions and who reacted are now shown (click on the reaction numbers) * Multiple search UI/UX improvements * Undo Send works for DMs too * Undo Send now restores the draft * UI: Side panel contains less so it can be thinner. Bottom bar added. * UI: frame count and spinner (optional) * Relay UI: sorting by score puts important relays at the top. * Relay UI: add more filters so all the bits are covered * Image and video loading is much faster (significant lag reduction) * Thread loading fix makes threads load far more reliably * Settings have reset-to-default buttons, so you don't get too lost. * Setting 'limit inbox seeking to inbox relays' may help avoid spam at the expense of possibly * Fix some bugs * And more updates

Nostur v1.18.1 nostr:npub1n0stur7q092gyverzc2wfc00e8egkrdnnqq3alhv7p072u89m5es5mk6h0

New in this version: * Floating mini video player * Videos: Save to library, Copy video URL, Add bookmark * Improved video stream / chat view * Top zaps on live chat * Posting to Picture-first * Profile view: Show interactions with you (conversations, reactions, zaps, reposts) * Profile view: Show actual reactions instead of only Likes * Improved search + Bookmark search * Detect nsfw / content-warning in posts * Show more to show reactions outside Web of Trust * Show more to show zaps outside Web of Trust * Support .avif image format * Support .mp3 format * Support .m4v video format * Improved zap verification for changed wallets * Improved outbox support * Show label on restricted posts * Low data mode: load media in app on tap instead of external browser * Many other bug fixes and performance improvements

Alby nostr:npub1getal6ykt05fsz5nqu4uld09nfj3y3qxmv8crys4aeut53unfvlqr80nfm

Latest two releases of Alby Go, 1.10 and 1.11, brought you lots of goodies: * BTC Map integration for quick access to global bitcoin merchants map * Confirm new NWC connections to your Alby Hub directly in Alby Go! No more copy-pasting or QR code scanning * Support for MoneyBadger Pay Pick n Pay QR payments in over 2000 stores in South Africa

ZEUS v0.10.0 nostr:npub1xnf02f60r9v0e5kty33a404dm79zr7z2eepyrk5gsq3m7pwvsz2sazlpr5

ZEUS v0.10.0 is now available. This release features the ability to renew channel leases, spin up multiple embedded wallets, Nostr Wallet Connect client support, and more. * Renewable channels * NWC client support * Ability to create multiple Embedded LND 'node in the phone' wallets * Ability to delete Embedded LND wallets * Embedded LND: v0.18.5-beta * New share button (share ZEUS QR images) * Tools: Export Activity CSVs, Developer tools, chantools * Activity: filter by max amount, memo, and note

Long-Form Content Eco

In the past two weeks, more than 463 long-form articles have been published, including over 91 articles on Bitcoin and more than 41 related to Nostr, accounting for 29% of the total content.

These articles about Nostr mainly explore the rise of Nostr as a decentralized platform that is reshaping the future of the internet. They emphasize Nostr's role in providing users with greater freedom, ownership, and fair monetization, particularly in the realm of content creation. The platform is positioned as a counter to centralized social media networks, offering uncensored interactions, enhanced privacy, and direct transactions. Many articles delve into Nostr’s potential to integrate with Bitcoin, creating a Layer 3 solution that promises to end the dominance of old internet structures. Discussions also cover the technical aspects of Nostr, such as the implementation of relays and group functionalities, as well as security concerns like account hacks. Furthermore, there is an exploration of the philosophical and anthropological dimensions of Nostr, with the rise of "Dark Nostr" being portrayed as a deeper expression of decentralized freedom.

The Bitcoin articles discuss the ongoing evolution of Bitcoin and its increasing integration into global financial systems. Many articles focus on the growing adoption of Bitcoin, particularly in areas like Argentina and the U.S., where Bitcoin is being used for rental payments and the establishment of a strategic Bitcoin reserve. Bitcoin is also portrayed as a response to the centralized financial system, with discussions about how it can empower individuals through financial sovereignty, provide a hedge against inflation, and create fairer monetization models for creators. Additionally, the articles explore the challenges and opportunities within the Bitcoin ecosystem, including the rise of Bitcoin ETFs, the development of Bitcoin mining, and the potential impact of AI on Bitcoin adoption. There is also emphasis on Bitcoin's cultural and economic implications, as well as the need for decentralized education and innovation to drive further adoption.

Thank you, nostr:npub1ygzsm5m9ndtgch9n22cwsx2clwvxhk2pqvdfp36t5lmdyjqvz84qkca2m5 nostr:npub1rsv7kx5avkmq74p85v878e9d5g3w626343xhyg76z5ctfc30kz7q9u4dke nostr:npub17wrn0xxg0hfq7734cfm7gkyx3u82yfrqcdpperzzfqxrjf9n7tes6ra78k nostr:npub1fxq5crl52mre7luhl8uqsa639p50853r3dtl0j0wwvyfkuk4f6ssc5tahv nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx nostr:npub19mf4jm44umnup4he4cdqrjk3us966qhdnc3zrlpjx93y4x95e3uq9qkfu2 nostr:npub1marc26z8nh3xkj5rcx7ufkatvx6ueqhp5vfw9v5teq26z254renshtf3g0 nostr:npub1uv0m8xc6q4cnj2p0tewmcgkyzg8cnteyhed0zv30ez03w6dzwvnqtu6gwl nostr:npub1ygzsm5m9ndtgch9n22cwsx2clwvxhk2pqvdfp36t5lmdyjqvz84qkca2m5 nostr:npub1mhcr4j594hsrnen594d7700n2t03n8gdx83zhxzculk6sh9nhwlq7uc226 nostr:npub1xzuej94pvqzwy0ynemeq6phct96wjpplaz9urd7y2q8ck0xxu0lqartaqn nostr:npub1gqgpfv65dz8whvyup942daagsmwauj0d8gtxv9kpfvgxzkw4ga4s4w9awr nostr:npub16dswlmzpcys0axfm8kvysclaqhl5zv20ueurrygpnnm7k9ys0d0s2v653f and others, for your work. Enriching Nostr’s long-form content ecosystem is crucial.

Nostriches Global Meet Ups

Recently, several Nostr events have been hosted in different countries. * The first Bitcoin Meetup organized by Mi Primer Bitcoin was successfully held on March 14, 2025, at Texijal Pizza in Apaneca. The event included Bitcoin education, networking, a Q&A session, and merchandise distribution, offering an exciting experience for all participants.
* The Btrust Space discussion was successfully held on March 13, 2024. The event focused on how to support Bitcoin developers, fund open-source contributions, and grow the Bitcoin ecosystem. The speakers included Bitcoin core contributors, Btrust CEO, engineering leads, and other project leaders.

Here is the upcoming Nostr event that you might want to check out.

• The Nostr Workshop, organized by YakiHonne and Bitcoin Safari, will take place online via Google Meet on March 17, 2025, at 7:00 PM (GMT+1). The event will introduce the Nostr ecosystem and Bitcoin payments, with participants learning about decentralized technology through YakiHonne and earning rewards. Register and verify your account to claim exclusive rewards, and invite friends to unlock additional rewards.
• The 2025 Bitcoin, Crypto Economy, and Law FAQ Webinar will be held online on March 20, 2025 (Thursday) from 12:00 to 13:00 Argentina time. The webinar will be hosted by Martin Paolantonio (Academic Director of the course) and Daniel Rybnik (Lawyer specializing in Banking, Corporate, and Financial Law). The session aims to introduce the academic program and explore Bitcoin, the crypto economy, and related legal issues.
• Bitcoin Educators Unconference 2025 will take place on April 10, 2025, at Bitcoin Park in Nashville, Tennessee, USA. This event is non-sponsored and follows an Unconference format, allowing all participants to apply as speakers and share their Bitcoin education experiences in a free and interactive environment. The event has open-sourced all its blueprints and Standard Operating Procedures (SOPs) to encourage global communities to organize similar Unconference events.

Additionally, We warmly invite event organizers who have held recent activities to reach out to us so we can work together to promote the prosperity and development of the Nostr ecosystem.

Thanks for reading! If there’s anything I missed, feel free to reach out and help improve the completeness and accuracy of my coverage.

@ 3bf0c63f:aefa459d

Drivechain comparison with Ethereum

Ethereum and other "smart contract platforms" capable of running turing-complete code and "developer-friendly" mindset and community have been running for years and they were able to produce a very low number of potentially useful "contracts".

What are these contracts, actually? (Considering Ethereum, but others are similar:) they are sidechains that run inside the Ethereum blockchain (and thus their verification and data storage are forced upon all Ethereum nodes). Users can peg-in to a contract by depositing money on it and peg-out by making a contract operation that sends money to a normal Ethereum address.

Now be generous and imagine these platforms are able to produce 3 really cool, useful ideas (out of many thousands of attempts): Bitcoin can copy these, turn them into 3 different sidechains, each running fixed, specific, optimized code. Bitcoin users can now opt to use these platforms by transferring coins to it – all that without damaging the nodes or the consensus protocol that has been running for years, and without forcing anyone to be aware of these chains.

The process of turning a useful idea into a sidechain doesn't come spontaneously, and can't be done by a single company (like often happens in Ethereum-land), it must be acknowledge by a rough consensus in the Bitcoin community that that specific sidechain with that specific design is a desirable thing, and ultimately approved by miners, as they're the ones that are going to be in charge of that.

@ 04cb16e4:2ec3e5d5

Wenn man etwas verkaufen will, muss man eine Geschichte über sein Produkt erzählen. Nur wenige können etwas damit anfangen, wenn du sagst: Unser Produkt enthält 50 Gramm Hafer (hoffentlich gentechnikfrei), 5 mittelgroße Erdbeeren, Spuren von Sesamschalen sowie einen Teelöffel Honig. So funktioniert das nicht. Dein Riegel braucht einen Namen und eine Geschichte.

Wenn wir über Krieg und Frieden sprechen, denn gibt es zumeist Zahlen, Fakten und Meinungen. Tausende von Kindern die in einem Krieg getötet werden sind eine schockierende Anzahl. Nimmst du die Zahlen weg und beschäftigst dich mit jedem einzelnen Schicksal, dann ist das unmöglich zu ertragen. Also kämpfen wir hier vor Ort, in Deutschland, zwar nicht mit Waffen gegeneinander, sondern mittels unserer Meinungen in Kombination mit zu vermittelnden relativen Wahrheiten. Da kommt das Ego ins Spiel. Wir wollen unbedingt Recht haben! Irgendeiner soll in diesem Meinungskampf am Ende als Gewinner dastehen. Weil er die besseren Argumente hat. Schließlich werden Emotionen mit Fakten vermischt und als Totschlagargumente in die Gegenfront geworfen.

Was aber, wenn man eine Geschichte über den Krieg erzählt, die jeden mitnehmen kann, ganz gleich, welche Meinung man zu den aktuell verhandelten Kampfschauplätzen hat? Alles Trennende wird aus der Erzählung herausgenommen und was bleibt, sind die zerstörerische Kraft des Krieges und die Verantwortung jedes einzelnen Menschen zu entscheiden, ob er dieses grausame Monster füttert oder eben nicht. In dem afrikanischen Märchen „Sheikhi“ basieren diese Entscheidungen nicht auf Fakten und Meinungen, sondern auf persönlichen Erfahrungen. Die Protagonisten nehmen uns mit in ihre Welt und lassen uns ihre inneren Kämpfe, Zweifel, Ängste und Hoffnungen miterleben. Wir können uns mit ihnen identifizieren, obwohl wir unter völlig anderen Bedingungen leben und sterben.

Hier kannst du das Buch direkt beim Verlag bestellen

Die alternative Buchmesse Seitenwechsel

Am Ende des Buches konnte ich gar nicht anders, als eine tiefe Sehnsucht nach Frieden und Einigkeit zu verspüren. Diese Sehnsucht basierte aber nicht mehr auf dem Bedürfnis, bessere Argumente als die vermeintliche Gegenseite zu haben, sondern vielmehr darauf, dass dieses verzweifelte Ringen und Hassen endlich zu einem Ende kommt. Nicht nur auf den Schlachtfeldern Asiens und Afrikas, sondern ebenfalls auf Facebook, X, den Straßen unserer Städte und im Krieg jedes Menschen gegen sich selbst. Inzwischen gelingt es mir immer öfter, mir einen bissigen Kommentar zu verkneifen, wenn jemand auf Facebook etwas schreibt, was ich unerträglich finde. Ich weiß, das ich ihn nicht vom Gegenteil überzeugen werde und das mein Kommentar das selbe Monster füttert, dass sich an den Opfern des Krieges satt isst.

Wenn es irgendwo Menschen auf der Welt gibt, die Mord und Folter verzeihen können, dann kann auch ich eine andere Meinung ertragen ohne rechthaberisch, arrogant und destruktiv zu werden. Notfalls gehe ich in den Wald und schreie.

https://mcdn.podbean.com/mf/web/9x9anxqcuity7639/Sheiki.mp3

@ 20986fb8:cdac21b3

The Traditional Hackathon: Brilliant Sparks with Limitations

For decades, hackathons have been the petri dishes of tech culture – frantic 24- or 48-hour coding marathons fueled by pizza, caffeine, and impossible optimism. From the first hackathon in 1999, when Sun Microsystems challenged Java developers to code on a Palm V in a day [1], to the all-night hack days at startups and universities, these events celebrated the hacker spirit. They gave us Facebook’s “Like” button and Chat features – iconic innovations born in overnight jams [1]. They spawned companies like GroupMe, which was coded in a few late-night hours and sold to Skype for $80 million a year later [2]. Hackathons became tech lore, synonymous with creativity unchained.

And yet, for all their electric energy and hype, traditional hackathons had serious limitations. They were episodic and offline – a once-in-a-blue-moon adrenaline rush rather than a sustainable process. A hackathon might gather 100 coders in a room over a weekend, then vanish until the next year. Low frequency, small scale, limited reach. Only those who could be on-site (often in Silicon Valley or elite campuses) could join. A brilliant hacker in Lagos or São Paulo would be left out, no matter how bright their ideas.

The outcomes of these sprint-like events were also constrained. Sure, teams built cool demos and won bragging rights. But in most cases, the projects were throwaway prototypes – “toy” apps that never evolved into real products or companies. It’s telling that studies found only about 5% of hackathon projects have any life a few months after the event [3]. Ninety-five percent evaporate – victims of that post-hackathon hangover, when everyone goes back to “real” work and the demo code gathers dust. Critics even dubbed hackathons “weekend wastedathons,” blasting their outputs as short-lived vaporware [3]. Think about it: a burst of creativity occurs, dozens of nifty ideas bloom… and then what? How many hackathon winners can you name that turned into enduring businesses? For every Carousell or EasyTaxi that emerged from a hackathon and later raised tens of millions [2], there were hundreds of clever mashups that never saw the light of day again.

The traditional hackathon model, as exciting as it was, rarely translated into sustained innovation. It was innovation in a silo: constrained by time, geography, and a lack of follow-through. Hackathons were events, not processes. They happened in a burst and ended just as quickly – a firework, not a sunrise.

Moreover, hackathons historically were insular. Until recently, they were largely run by and for tech insiders. Big tech companies did internal hackathons to juice employee creativity (Facebook’s famous all-nighters every few weeks led to Timeline and tagging features reaching a billion users [1]), and organizations like NASA and the World Bank experimented with hackathons for civic tech. But these were exceptions that proved the rule: hackathons were special occasions, not business-as-usual. Outside of tech giants, few organizations had the bandwidth or know-how to host them regularly. If you weren’t Google, Microsoft, or a well-funded startup hub, hackathons remained a novelty.

In fact, the world’s largest hackathon today is Microsoft’s internal global hackathon – with 70,000 employees collaborating across 75 countries [4] – an incredible feat, but one only a corporate titan could pull off. Smaller players could only watch and wonder.

The limitations were clear: hackathons were too infrequent and inaccessible to tap the full global talent pool, too short-lived to build anything beyond a prototype, and too isolated to truly change an industry. Yes, they produced amazing moments of genius – flashbulbs of innovation. But as a mechanism for continuous progress, the traditional hackathon was lacking. As an investor or tech leader, you might cheer the creativity but ask: Where is the lasting impact? Where is the infrastructure that turns these flashes into a steady beam of light?

In the spirit of Clay Christensen’s Innovator’s Dilemma, incumbents often dismissed hackathon projects as mere toys – interesting but not viable. And indeed, “the next big thing always starts out being dismissed as a toy” [5]. Hackathons generated plenty of toys, but rarely the support system to turn those toys into the next big thing. The model was ripe for reinvention. Why, in the 2020s, were we still innovating with a 1990s playbook? Why limit breakthrough ideas to a weekend or a single location? Why allow 95% of nascent innovations to wither on the vine? These questions hung in the air, waiting for an answer.

Hackathons 2.0 – DoraHacks and the First Evolution (2020–2024)

Enter DoraHacks. In the early 2020s, DoraHacks emerged like a defibrillator for the hackathon format, jolting it to new life. DoraHacks 1.0 (circa 2020–2024) was nothing less than the reinvention of the hackathon – an upgrade from Hackathon 1.0 to Hackathon 2.0. It took the hackathon concept, supercharged it, scaled it, and extended its reach in every dimension. The result was a global hacker movement, a platform that transformed hackathons from one-off sprints into a continuous engine for tech innovation. How did DoraHacks revolutionize the hackathon? Let’s count the ways:

From 24 Hours to 24 Days (or 24 Weeks!)

DoraHacks stretched the timeframe of hackathons, unlocking vastly greater potential. Instead of a frantic 24-hour dash, many DoraHacks-supported hackathons ran for several weeks or even months. This was a game-changer. Suddenly, teams had time to build serious prototypes, iterate, and polish their projects. A longer format meant hackathon projects could evolve beyond the rough demo stage. Hackers could sleep (occasionally!), incorporate user feedback, and transform a kernel of an idea into a working MVP. The extended duration blurred the line between a hackathon and an accelerator program – but with the open spirit of a hackathon intact. For example, DoraHacks hackathons for blockchain startups often ran 6–8 weeks, resulting in projects that attracted real users and investors by the end. The extra time turned hackathon toys into credible products. It was as if the hackathon grew up: less hack, more build (“BUIDL”). By shattering the 24-hour norm, DoraHacks made hackathons far more productive and impactful.

From Local Coffee Shops to Global Online Arenas

DoraHacks moved hackathons from physical spaces into the cloud, unleashing global participation. Pre-2020, a hackathon meant being in a specific place – say, a warehouse in San Francisco or a university lab – shoulder-to-shoulder with a local team. DoraHacks blew the doors off that model with online hackathons that anyone, anywhere could join. Suddenly, a developer in Nigeria could collaborate with a designer in Ukraine and a product thinker in Brazil, all in the same virtual hackathon. Geography ceased to be a limit. When DoraHacks hosted the Naija HackAtom for African blockchain devs, it drew over 500 participants (160+ developers) across Nigeria’s tech community [6]. In another event, thousands of hackers from dozens of countries logged into a DoraHacks virtual venue to ideate and compete. This global reach did more than increase headcount – it brought diverse perspectives and problems into the innovation mix. A fintech hackathon might see Latin American coders addressing remittances, or an AI hackathon see Asian and African participants applying machine learning to local healthcare challenges. By going online, hackathons became massively inclusive. DoraHacks effectively democratized access to innovation competitions: all you needed was an internet connection and the will to create. The result was a quantum leap in both the quantity and quality of ideas. No longer were hackathons an elitist sport; they became a global innovation free-for-all, open to talent from every corner of the world.

From Dozens of Participants to Tens of Thousands

Scale was another pillar of the DoraHacks revolution. Traditional hackathons were intimate affairs (dozens, maybe a few hundred participants at best). DoraHacks helped orchestrate hackathons an order of magnitude larger. We’re talking global hackathons with thousands of developers and multi-million dollar prize pools. For instance, in one 2021 online hackathon, nearly 7,000 participants submitted 550 projects for $5 million in prizes [7] – a scale unimaginable in the early 2010s. DoraHacks itself became a nexus for these mega-hackathons. The platform’s hackathons in the Web3 space routinely saw hundreds of teams competing for prizes sometimes exceeding $1 million. This scale wasn’t just vanity metrics; it meant a deeper talent bench attacking problems and a higher probability that truly exceptional projects would emerge. By casting a wide net, DoraHacks events captured star teams that might have been overlooked in smaller settings. The proof is in the outcomes: 216 builder teams were funded with over $5 million in one DoraHacks-powered hackathon series on BNB Chain [8] – yes, five million dollars, distributed to over two hundred teams as seed funding. That’s not a hackathon, that’s an economy! The prize pools ballooned from pizza money to serious capital, attracting top-tier talent who realized this hackathon could launch my startup. As a result, projects coming out of DoraHacks were not just weekend hacks – they were venture-ready endeavors. The hackathon graduated from a science fair to a global startup launchpad.

From Toy Projects to Real Startups (Even Unicorns)

Here’s the most thrilling part: DoraHacks hackathons started producing not just apps, but companies. And some of them turned into unicorns (companies valued at $1B+). We saw earlier the rare cases of pre-2020 hackathon successes like Carousell (a simple idea at a 2012 hackathon that became a $1.1B valued marketplace [2]) or EasyTaxi (born in a hackathon, later raising $75M and spanning 30 countries [2]). DoraHacks turbocharged this phenomenon. By providing more time, support, and follow-up funding, DoraHacks-enabled hackathons became cradles of innovation where raw hacks matured into fully-fledged ventures. Take 1inch Network for example – a decentralized finance aggregator that started as a hackathon project in 2019. Sergej Kunz and Anton Bukov built a prototype at a hackathon and kept iterating. Fast forward: 1inch has now processed over $400 billion in trading volume [9] and became one of the leading platforms in DeFi. Or consider the winners of DoraHacks Web3 hackathons: many have gone on to raise multimillion-dollar rounds from top VCs. Hackathons became the front door to the startup world – the place where founders made their debut. A striking illustration was the Solana Season Hackathons: projects like STEPN, a move-to-earn app, won a hackathon track in late 2021 and shortly after grew into a sensation with a multi-billion dollar token economy [10]. These are not isolated anecdotes; they represent a trend DoraHacks set in motion. The platform’s hackathons produced a pipeline of fundable, high-impact startups. In effect, DoraHacks blurred the line between a hackathon and a seed-stage incubator. The playful hacker ethos remained, but now the outcomes were much more than bragging rights – they were companies with real users, revenue, and valuations. To paraphrase investor Chris Dixon, DoraHacks took those “toys” and helped nurture them into the next big things [5].

In driving this first evolution of the hackathon, DoraHacks didn’t just improve on an existing model – it created an entirely new innovation ecosystem. Hackathons became high-frequency, global, and consequential. What used to be a weekend thrill became a continuous pipeline for innovation. DoraHacks events started churning out hundreds of viable projects every year, many of which secured follow-on funding. The platform provided not just the event itself, but the after-care: community support, mentorship, and links to investors and grants (through initiatives like DoraHacks’ grant programs and quadratic funding rounds).

By 2024, the results spoke volumes. DoraHacks had grown into the world’s most important hackathon platform – the beating heart of a global hacker movement spanning blockchain, AI, and beyond. The numbers tell the story. Over nine years, DoraHacks supported 4,000+ projects in securing more than $30 million in funding [11]; by 2025, that figure skyrocketed as 21,000+ startups and developer teams received over $80 million via DoraHacks-supported hackathons and grants [12]. This is not hype – this is recorded history. According to CoinDesk, “DoraHacks has made its mark as a global hackathon organizer and one of the world’s most active multi-chain Web3 developer platforms” [11]. Major tech ecosystems took notice. Over 40 public blockchain networks (L1s and L2s) – from Solana to Polygon to Avalanche – partnered with DoraHacks to run their hackathons and open innovation programs [13]. Blockworks reported that DoraHacks became a “core partner” to dozens of Web3 ecosystems, providing them access to a global pool of developers [13]. In the eyes of investors, DoraHacks itself was key infrastructure: “DoraHacks is key to advancing the development of the infrastructure for Web3,” noted one VC backing the platform [13].

In short, by 2024 DoraHacks had transformed the hackathon from a niche event into a global innovation engine. It proved that hackathons at scale can consistently produce real, fundable innovation – not just one-off gimmicks. It connected hackers with resources and turned isolated hacks into an evergreen, worldwide developer movement. This was Hackathons 2.0: bigger, longer, borderless, and far more impactful than ever before.

One might reasonably ask: Can it get any better than this? DoraHacks had seemingly cracked the code to harness hacker energy for lasting innovation. But the team behind DoraHacks wasn’t done. In fact, they were about to unveil something even more radical – a catalyst to push hackathons into a new epoch entirely. If DoraHacks 1.0 was the evolution, what came next would be a revolution.

The Agentic Hackathon: BUIDL AI and the Second Revolution

In 2024, DoraHacks introduced BUIDL AI, and with it, the concept of the Agentic Hackathon. If hackathons at their inception were analog phones, and DoraHacks 1.0 made them smartphones, then BUIDL AI is like giving hackathons an AI co-pilot – a self-driving mode. It’s not merely an incremental improvement; it’s a second revolution. BUIDL AI infused hackathons with artificial intelligence, automation, and agency (hence “agentic”), fundamentally changing how these events are organized and experienced. We are now entering the Age of Agentic Innovation, where hackathons run with the assistance of AI agents can occur with unprecedented frequency, efficiency, and intelligence.

So, what exactly is an Agentic Hackathon? It’s a hackathon where AI-driven agents augment the entire process – from planning and judging to participant support – enabling a scale and speed of innovation that was impossible before. In an agentic hackathon, AI is the tireless co-organizer working alongside humans. Routine tasks that used to bog down organizers are now handled by intelligent algorithms. Imagine hackathons that practically run themselves, continuously, like an “always-on” tournament of ideas. With BUIDL AI, DoraHacks effectively created self-driving hackathons – autonomous, efficient, and capable of operating 24/7, across multiple domains, simultaneously. This isn’t science fiction; it’s happening now. Let’s break down how BUIDL AI works and why it 10x’d hackathon efficiency overnight:

AI-Powered Judging and Project Review – 10× Efficiency Boost

One of the most labor-intensive aspects of big hackathons is judging hundreds of project submissions. It can take organizers weeks of effort to sift the high-potential projects from the rest. BUIDL AI changes that. It comes with a BUIDL Review module – an AI-driven judging system that can intelligently evaluate hackathon projects on multiple dimensions (completeness, originality, relevance to the hackathon theme, etc.) and automatically filter out low-quality submissions [14]. It’s like having an army of expert reviewers available instantly. The result? What used to require hundreds of human-hours now happens in a flash. DoraHacks reports that AI-assisted review has improved hackathon organization efficiency by more than 10× [14]. Think about that: a process that might have taken a month of tedious work can be done in a few days or less, with AI ensuring consistency and fairness in scoring. Organizers can now handle massive hackathons without drowning in paperwork, and participants get quicker feedback. The AI doesn’t replace human judges entirely – final decisions still involve experts – but it augments them, doing the heavy lifting of initial evaluation. This means hackathons can accept more submissions, confident that AI will help triage them. No more cutting off sign-ups because “we can’t review them all.” The machine scale is here. In an agentic hackathon, no good project goes unseen due to bandwidth constraints – the AI makes sure of that.

Automated Marketing and Storytelling

Winning a hackathon is great, but if nobody hears about it, the impact is muted. Traditionally, after a hackathon ended, organizers would manually compile results, write blog posts, thank sponsors – tasks that, while important, take time and often get delayed. BUIDL AI changes this too. It features an Automated Marketing capability that can generate post-hackathon reports and content with a click [14]. Imagine an AI that observes the entire event (the projects submitted, the winners, the tech trends) and then writes a polished summary: highlighting the best ideas, profiling the winning teams, extracting insights (“60% of projects used AI in healthcare this hackathon”). BUIDL AI does exactly that – it automatically produces a hackathon “highlight reel” and summary report [14]. This not only saves organizers the headache of writing marketing copy, but it also amplifies the hackathon’s reach. Within hours of an event, a rich recap can be shared globally, showcasing the innovations and attracting attention to the teams. Sponsors and partners love this, as their investment gets publicized promptly. Participants love it because their work is immediately celebrated and visible. In essence, every hackathon tells a story, and BUIDL AI ensures that story spreads far and wide – instantly. This kind of automated storytelling turns each hackathon into ongoing content, fueling interest and momentum for the next events. It’s a virtuous cycle: hackathons create innovations, AI packages the narrative, that narrative draws in more innovators.

One-Click Launch and Multi-Hackathon Management

Perhaps the most liberating feature of BUIDL AI is how it obliterates the logistical hurdles of organizing hackathons. Before, setting up a hackathon was itself a project – coordinating registrations, judges, prizes, communications, all manually configured. DoraHacks’ BUIDL AI introduces a one-click hackathon launch tool [14]. Organizers simply input the basics (theme, prize pool, dates, some judging criteria) and the platform auto-generates the event page, submission portal, judging workflow, and more. It’s as easy as posting a blog. This dramatically lowers the barrier for communities and companies to host hackathons. A small startup or a university club can now launch a serious global hackathon without a dedicated team of event planners. Furthermore, BUIDL AI supports Multi-Hackathon Management, meaning one organization can run multiple hackathons in parallel with ease [14]. In the past, even tech giants struggled to overlap hackathons – it was too resource-intensive. Now, an ecosystem could run, say, a DeFi hackathon, an AI hackathon, and an IoT hackathon all at once, with a lean team, because AI is doing the juggling in the back-end. The launch of BUIDL AI made it feasible to organize 12 hackathons a year – or even several at the same time – something unimaginable before [14]. The platform handles participant onboarding, sends reminders, answers common queries via chatbots, and keeps everything on track. In essence, BUIDL AI turns hackathon hosting into a scalable service. Just as cloud computing platforms let you spin up servers on demand, DoraHacks lets you spin up innovation events on demand. This is a tectonic shift: hackathons can now happen as frequently as needed, not as occasionally as resources allow. We’re talking about the birth of perpetual hackathon culture. Hackathons are no longer rare spark events; they can be continuous flames, always burning, always on.

Real-Time Mentor and Agentic Assistance

The “agentic” part of Agentic Hackathons isn’t only behind the scenes. It also touches the participant experience. With AI integration, hackers get smarter tools and support. For instance, BUIDL AI can include AI assistants that answer developers’ questions during the event (“How do I use this API?” or “Any example code for this algorithm?”), acting like on-demand mentors. It can match teams with potential collaborators or suggest resources. Essentially, every hacker has an AI helper at their side, reducing frustration and accelerating progress. Coding issues that might take hours to debug can be resolved in minutes with an AI pair programmer. This means project quality goes up and participants learn more. It’s as if each team has an extra member – an tireless, all-knowing one. This agentic assistance embodies the vision that “everyone is a hacker” [14] – because AI tools enable even less-experienced participants to build something impressive. The popularization of AI has automated repetitive grunt work and amplified what small teams can achieve [14], so the innovation potential of hackathons is far greater than before [14]. In an agentic hackathon, a team of two people with AI assistants can accomplish what a team of five might have in years past. The playing field is leveled and the creative ceiling is raised.

What do all these advances add up to? Simply this: Hackathons have evolved from occasional bouts of inspiration into a continuous, AI-optimized process of innovation. We have gone from Hackathons 2.0 to Hackathons 3.0 – hackathons that are autonomous, persistent, and intelligent. It’s a paradigm shift. The hackathon is no longer an event you attend; it’s becoming an environment you live in. With BUIDL AI, DoraHacks envisions a world where “Hackathons will enter an unprecedented era of automation and intelligence, allowing more hackers, developers, and open-source communities around the world to easily initiate and participate” [14]. Innovation can happen anytime, anywhere – because the infrastructure to support it runs 24/7 in the cloud, powered by AI. The hackathon has become an agentic platform, always ready to transform ideas into reality.

Crucially, this isn’t limited to blockchain or any single field. BUIDL AI is general-purpose. It is as relevant for an AI-focused hackathon as for a climate-tech or healthcare hackathon. Any domain can plug into this agentic hackathon platform and reap the benefits of higher frequency and efficiency. This heralds a future where hackathons become the default mode for problem-solving. Instead of committees and R&D departments working in silos, companies and communities can throw problems into the hackathon arena – an arena that is always active. It’s like having a global innovation engine humming in the background, ready to tackle challenges at a moment’s notice.

To put it vividly: If DoraHacks 1.0 turned hackathons into a high-speed car, DoraHacks 2.0 with BUIDL AI made it a self-driving car with the pedal to the metal. The roadblocks of cost, complexity, and time – gone. Now, any organization can accelerate from 0 to 60 on the innovation highway without a pit stop. Hackathons can be as frequent as blog updates, as integrated into operations as sprint demos. Innovation on demand, at scale – that’s the power of the Agentic Hackathon.

Innovation On-Demand: How Agentic Hackathons Benefit Everyone

The advent of agentic hackathons isn’t just a cool new toy for the tech community – it’s a transformative tool for businesses, developers, and entire industries. We’re entering an era where anyone with a vision can harness hackathons-as-a-service to drive innovation. Here’s how different players stand to gain from this revolution:

AI Companies – Turbocharging Ecosystem Growth

For AI-focused companies (think OpenAI, Google, Microsoft, Stability AI and the like), hackathons are goldmines of creative uses for their technology. Now, with agentic hackathons, an AI company can essentially run a continuous developer conference for their platform. For example, OpenAI can host always-on hackathons for building applications with GPT-4 or DALL-E. This means thousands of developers constantly experimenting and showcasing what the AI can do – effectively crowdsourcing innovation and killer apps for the AI platform. The benefit? It dramatically expands the company’s ecosystem and user base. New use cases emerge that the company’s own team might never have imagined. (It was independent hackers who first showed how GPT-3 could draft legal contracts or generate game levels – insights that came from hackathons and community contests.) With BUIDL AI, an AI company could spin up monthly hackathons with one click, each focusing on a different aspect (one month NLP, next month robotics, etc.). This is a marketing and R&D force multiplier. Instead of traditional, expensive developer evangelism tours, the AI does the heavy lifting to engage devs globally. The company’s product gets improved and promoted at the same time. In essence, every AI company can now launch a Hackathon League to promote their APIs/models. It’s no coincidence Coinbase just hosted its first AI hackathon to bridge crypto and AI [15] – they know that to seed adoption of a new paradigm, hackathons are the way. Expect every AI platform to do the same: continuous hackathons to educate developers, generate content (demos, tutorials), and identify standout talent to hire or fund. It’s community-building on steroids.

L1s/L2s and Tech Platforms – Discovering the Next Unicorns

For blockchain Layer1/Layer2 ecosystems, or any tech platform (cloud providers, VR platforms, etc.), hackathons are the new deal flow. In the Web3 world, it’s widely recognized that many of the best projects and protocols are born in hackathons. We saw how 1inch started as a hackathon project and became a DeFi unicorn [9]. There’s also Polygon (which aggressively runs hackathons to find novel dApps for its chain) and Filecoin (which used hackathons to surface storage applications). By using DoraHacks and BUIDL AI, these platforms can now run high-frequency hackathons to continuously source innovation. Instead of one or two big events a year, they can have a rolling program – a quarterly hackathon series or even simultaneous global challenges – to keep developers building all the time. The ROI is huge: the cost of running a hackathon (even with decent prizes) is trivial compared to acquiring a thriving new startup or protocol for your ecosystem. Hackathons effectively outsource initial R&D to passionate outsiders, and the best ideas bubble up. Solana’s hackathons led to star projects like Phantom and Solend gaining traction in its ecosystem. Facebook’s internal hackathons gave birth to features that kept the platform dominant [1]. Now any platform can do this externally: use hackathons as a radar for talent and innovation. Thanks to BUIDL AI, a Layer-2 blockchain, even if its core team is small, can manage a dozen parallel bounties and hackathons – one focusing on DeFi, one on NFTs, one on gaming, etc. The AI will help review submissions and manage community questions, so the platform’s devrel team doesn’t burn out. The result is an innovation pipeline feeding the platform’s growth. The next unicorn startup or killer app is identified early and supported. In effect, hackathons become the new startup funnel for VCs and ecosystems. We can expect venture investors to lurk in these agentic hackathons because that’s where the action is – the garages of the future are now cloud hackathon rooms. As Paul Graham wrote, “hackers and painters are both makers” [16], and these makers will paint the future of technology on the canvas of hackathon platforms.

Every Company and Community – Innovation as a Continuous Process

Perhaps the most profound impact of BUIDL AI is that it opens up hackathons to every organization, not just tech companies. Any company that wants to foster innovation – be it a bank exploring fintech, a hospital network seeking healthtech solutions, or a government looking for civic tech ideas – can leverage agentic hackathons. Innovation is no longer a privilege of the giant tech firms; it’s a cloud service accessible to all. For example, a city government could host a year-round hackathon for smart city solutions, where local developers continuously propose and build projects to improve urban life. The BUIDL AI platform could manage different “tracks” for transportation, energy, public safety, etc., with monthly rewards for top ideas. This would engage the community and yield a constant stream of pilot projects, far more dynamically than traditional RFP processes. Likewise, any Fortune 500 company that fears disruption (and who doesn’t?) can use hackathons to disrupt itself positively – inviting outsiders and employees to hack on the company’s own challenges. With the agentic model, even non-technical companies can do this without a hitch; the AI will guide the process, ensuring things run smoothly. Imagine hackathons as part of every corporate strategy department’s toolkit – continuously prototyping the future. As Marc Andreessen famously said, “software is eating the world” – and now every company can have a seat at the table by hosting hackathons to software-ize their business problems. This could democratize innovation across industries. The barrier to trying out bold ideas is so low (a weekend of a hackathon vs. months of corporate planning) that more wild, potentially disruptive ideas will surface from within companies. And with the global reach of DoraHacks, they can bring in external innovators too. Why shouldn’t a retail company crowdsource AR shopping ideas from global hackers? Why shouldn’t a pharma company run bioinformatics hackathons to find new ways to analyze data? There is no reason not to – the agentic hackathon makes it feasible and attractive. Hackathon-as-a-service is the new innovation department. Use it or risk being out-innovated by those who do.

All these benefits boil down to a simple but profound shift: hackathons are becoming a permanent feature of the innovation landscape, rather than a novelty. They are turning into an always-available resource, much like cloud computing or broadband internet. Need fresh ideas or prototypes? Spin up a hackathon and let the global talent pool tackle it. Want to engage your developer community? Launch a themed hackathon and give them a stage. Want to test out 10 different approaches to a problem? Run a hackathon and see what rises to the top. We’re effectively seeing the realization of what one might call the Innovation Commons – a space where problems and ideas are continuously matched, and solutions are rapidly iterated. And AI is the enabler that keeps this commons humming efficiently, without exhausting the human facilitators.

It’s striking how this addresses the classic pitfalls identified in hackathon critiques: sustainability and follow-through. In the agentic model, hackathons are no longer isolated bursts. They can connect to each other (winning teams from one hackathon can enter an accelerator or another hackathon next month). BUIDL AI can track teams and help link them with funding opportunities, closing the loop that used to leave projects orphaned after the event. A great project doesn’t die on Sunday night; it’s funneled into the next stage automatically (perhaps an AI even suggests which grant to apply for, which partner to talk to). This way, innovations have a life beyond the demo day, systematically.

We should also recognize a more philosophical benefit: the culture of innovation becomes more experimental, meritocratic, and fast-paced. In a world of agentic hackathons, the motto is “Why not prototype it? Why not try it now?” – because spinning up the environment to do so is quick and cheap. This mindset can permeate organizations and communities, making them more agile and bold. The cost of failure is low (a few weeks of effort), and the potential upside is enormous (finding the next big breakthrough). It creates a safe sandbox for disruptive ideas – addressing the Innovator’s Dilemma by structurally giving space to those ‘toy’ ideas to prove themselves [5]. Companies no longer have to choose between core business and experimentation; they can allocate a continuous hackathon track to the latter. In effect, DoraHacks and BUIDL AI have built an innovation factory – one that any visionary leader can rent for the weekend (or the whole year).

From Like Button to Liftoff: Hackathons as the Cradle of Innovation

To truly appreciate this new era, it’s worth reflecting on how many game-changing innovations started as hackathon projects or hackathon-like experiments – often despite the old constraints – and how much more we can expect when those constraints are removed. History is full of examples that validate the hackathon model of innovation:

Facebook’s DNA was shaped by hackathons

Mark Zuckerberg himself has credited the company’s internal hackathons for some of Facebook’s most important features. The Like button, Facebook Chat, and Timeline all famously emerged from engineers pulling all-nighters at hackathons [1]. An intern’s hackathon prototype for tagging people in comments was shipped to a billion users just two weeks later [1]. Facebook’s ethos “Move fast and break things” was practically the hackathon ethos formalized. It is no stretch to say Facebook won over MySpace in the 2000s because its culture of rapid innovation (fueled by hackathons) let it out-innovate its rival [1]. If hackathons did that within one company, imagine a worldwide network of hackathons – the pace of innovation everywhere could resemble that hypergrowth.

Google and the 20% Project

Google has long encouraged employees to spend 20% of time on side projects, which is a cousin of the hackathon idea – unstructured exploration. Gmail and Google News were born this way. Additionally, Google has hosted public hackathons around its APIs (like Android hackathons) that spurred the creation of countless apps. The point is, Google institutionalized hacker-style experimentation and reaped huge rewards. With agentic hackathons, even companies without Google’s resources can institutionalize experimentation. Every weekend can be a 20% time for the world’s devs using these platforms.

Open Source Movements

Open Source Movements have benefitted from hackathons (“code sprints”) to develop critical software. The entire OpenBSD operating system had regular hackathons that were essential to its development [3]. In more recent times, projects like Node.js or TensorFlow have organized hackathons to build libraries and tools. The result: stronger ecosystems and engaged contributors. DoraHacks embraces this, positioning itself as “the leading global hackathon community and open source developer incentive platform” [17]. The synergy of open source and hackathons (both decentralized, community-driven, merit-based) is a powerful engine. We can foresee open source projects launching always-on hackathons via BUIDL AI to continuously fix bugs, add features, and reward contributors. This could rejuvenate the open source world by providing incentives (through hackathon prizes) and recognition in a structured way.

The Startup World

The Startup World has hackathons to thank for many startups. We’ve mentioned Carousell (from a Startup Weekend hackathon, now valued over $1B [2]) and EasyTaxi (Startup Weekend Rio, went on to raise $75M [2]). Add to that list Zapier (integrations startup, conceived at a hackathon), GroupMe (acquired by Skype as noted), Instacart (an early version won a hackathon at Y Combinator Demo Day, legend has it), and numerous crypto startups (the founders of Ethereum itself met and collaborated through hackathons and Bitcoin meetups!). When Coinbase wants to find the next big thing in on-chain AI, they host a hackathon [15]. When Stripe wanted more apps on its payments platform, it ran hackathons and distributed bounties. This model just works. It identifies passionate builders and gives them a springboard. With agentic hackathons, that springboard is super-sized. It’s always there, and it can catch far more people. The funnel widens, so expect even more startups to originate from hackathons. It’s quite plausible that the biggest company of the 2030s won’t be founded in a garage – it will be born out of an online hackathon, formed by a team that met in a Discord server, guided by an AI facilitator, and funded within weeks on a platform like DoraHacks. In other words, the garage is going global and AI-powered.

Hackers & Painters – The Creative Connection

Paul Graham, in Hackers & Painters, drew an analogy between hacking and painting as creative endeavors [16]. Hackathons are where that creative energy concentrates and explodes. Many great programmers will tell you their most inspired work happened in a hackathon or skunkworks setting – free of bureaucratic restraints, in a flow state of creation. By scaling and multiplying hackathons, we are effectively amplifying the global creative capacity. We might recall the Renaissance when artists and inventors thrived under patronage and in gatherings – hackathons are the modern Renaissance workshops. They combine art, science, and enterprise. The likes of Leonardo da Vinci would have been right at home in a hackathon (he was notorious for prototyping like a madman). In fact, consider how hackathons embody the solution to the Innovator’s Dilemma: they encourage working on projects that seem small or “not worth it” to incumbents, which is exactly where disruptive innovation often hides [5]. By institutionalizing hackathons, DoraHacks is institutionalizing disruption – making sure the next Netflix or Airbnb isn’t missed because someone shrugged it off as a toy.

We’ve gone from a time when hackathons were rare and local to a time when they are global and constant. This is a pivotal change in the innovation infrastructure of the world. In the 19th century, we built railroads and telegraphs that accelerated the Industrial Revolution, connecting markets and minds. In the 20th century, we built the internet and the World Wide Web, unleashing the Information Revolution. Now, in the 21st century, DoraHacks and BUIDL AI are building the “Innovation Highway” – a persistent, AI-enabled network connecting problem-solvers to problems, talent to opportunities, capital to ideas, across the entire globe, in real time. It’s an infrastructure for innovation itself.

A Grand Vision: The New Infrastructure of Global Innovation

We stand at an inflection point. With DoraHacks and the advent of agentic hackathons, innovation is no longer confined to ivory labs, Silicon Valley offices, or once-a-year events. It is becoming a continuous global activity – an arena where the best minds and the boldest ideas meet, anytime, anywhere. This is a future where innovation is as ubiquitous as Wi-Fi and as relentless as Moore’s Law. It’s a future DoraHacks is actively building, and the implications are profound.

Picture a world a few years from now, where DoraHacks+BUIDL AI is the default backbone for innovation programs across industries. This platform is buzzing 24/7 with hackathons on everything from AI-driven healthcare to climate-change mitigation to new frontiers of art and entertainment. It’s not just for coders – designers, entrepreneurs, scientists, anyone with creative impulse plugs into this network. An entrepreneur in London has a business idea at 2 AM; by 2:15 AM, she’s on DoraHacks launching a 48-hour hackathon to prototype it, with AI coordinating a team of collaborators from four different continents. Sounds crazy? It will be commonplace. A government in Asia faces a sudden environmental crisis; they host an urgent hackathon via BUIDL AI and within days have dozens of actionable tech solutions from around the world. A venture fund in New York essentially “outsources” part of its research to the hackathon cloud – instead of merely requesting pitch decks, they sponsor open hackathons to see real prototypes first. This is agentic innovation in action – fast, borderless, and intelligent.

In this coming era, DoraHacks will be as fundamental to innovation as GitHub is to code or as AWS is to startups. It’s the platform where innovation lives. One might even call it the “GitHub of Innovation” – a social and technical layer where projects are born, not just stored. Already, DoraHacks calls itself “the global hacker movement” [17], and with BUIDL AI it becomes the autopilot of that movement. It’s fitting to think of it as part of the global public infrastructure for innovation. Just as highways move goods and the internet moves information, DoraHacks moves innovation itself – carrying ideas from inception to implementation at high speed.

When history looks back at the 2020s, the arrival of continuous, AI-driven hackathons will be seen as a key development in how humanity innovates. The vision is grand, but very tangible: Innovation becomes an everlasting hackathon. Think of it – the hacker ethos spreading into every corner of society, an eternal challenge to the status quo, constantly asking “How can we improve this? How can we reinvent that?” and immediately rallying the talent to do it. This is not chaos; it’s a new form of organized, decentralized R&D. It’s a world where any bold question – “Can we cure this disease? Can we educate children better? Can we make cities sustainable?” – can trigger a global hackathon and yield answers in days or weeks, not years. A world where innovation isn’t a scarce resource, jealously guarded by few, but a common good, an open tournament where the best solution wins, whether it comes from a Stanford PhD or a self-taught coder in Lagos.

If this sounds idealistic, consider how far we’ve come: Hackathons went from obscure coder meetups to the engine behind billion-dollar businesses and critical global tech (Bitcoin itself is a product of hacker culture!). With DoraHacks’s growth and BUIDL AI’s leap, the trajectory is set for hackathons to become continuous and ubiquitous. The technology and model are in place. It’s now about execution and adoption. And the trend is already accelerating – more companies are embracing open innovation, more developers are working remotely and participating in online communities, and AI is rapidly advancing as a co-pilot in all creative endeavors.

DoraHacks finds itself at the center of this transformation. It has the first-mover advantage, the community, and the vision. The company’s ethos is telling: “Funding the everlasting hacker movement” is one of their slogans [18]. They see hackathons as not just events but a movement that must be everlasting – a permanent revolution of the mind. With BUIDL AI, DoraHacks is providing the engine to make it everlasting. This hints at a future where DoraHacks+BUIDL AI is part of the critical infrastructure of global innovation, akin to a utility. It’s the innovation grid, and when you plug into it, magic happens.

Marc Andreessen’s writings often speak about “building a better future” with almost manifest destiny fervor. In that spirit, one can boldly assert: Agentic hackathons will build our future, faster and better. They will accelerate solutions to humanity’s toughest challenges by tapping a broader talent pool and iterating faster than ever. They will empower individuals – giving every creative mind on the planet the tools, community, and opportunity to make a real impact, immediately, not someday. This is deeply democratizing. It resonates with the ethos of the early internet – permissionless innovation. DoraHacks is bringing that ethos to structured innovation events and stretching them into an ongoing fabric.

In conclusion, we are witnessing a paradigm shift: Hackathons reinvented, innovation unchained. The limitations of the old model are gone, replaced by a new paradigm where hackathons are high-frequency, AI-augmented, and outcome-oriented. DoraHacks led this charge in the 2020–2024 period, and with BUIDL AI, it’s launching the next chapter – the Age of Agentic Innovation. For investors and visionaries, this is a call to action. We often talk about investing in “infrastructure” – well, this is investing in the infrastructure of innovation itself. Backing DoraHacks and its mission is akin to backing the builders of a transcontinental railroad or an interstate highway, except this time the cargo is ideas and breakthroughs. The network effects are enormous: every additional hackathon and participant adds value to the whole ecosystem, in a compounding way. It’s a positive-sum game of innovation. And DoraHacks is poised to be the platform and the community that captures and delivers that value globally.

DoraHacks reinvented hackathons – it turned hackathons from sporadic stunts into a sustained methodology for innovation. In doing so, it has thrown open the gates to an era where innovation can be agentic: self-driving, self-organizing, and ceaseless. We are at the dawn of this new age. It’s an age where, indeed, “he who has the developers has the world” [14] – and DoraHacks is making sure that every developer, every hacker, every dreamer anywhere can contribute to shaping our collective future. The grand vista ahead is one of continuous invention and discovery, powered by a global hive mind of hackers and guided by AI. DoraHacks and BUIDL AI stand at the helm of this movement, as the architects of the “innovation rails” on which we’ll ride. It’s not just a platform, it’s a revolutionary infrastructure – the new railroad, the new highway system for ideas. Buckle up, because with DoraHacks driving, the age of agentic innovation has arrived, and the future is hurtling toward us at hackathon speed. The hackathon never ends – and that is how we will invent a better world.

References

[1] Vocoli. (2015). Facebook’s Secret Sauce: The Hackathon. https://www.vocoli.com/blog/june-2015/facebook-s-secret-sauce-the-hackathon/
[2] Analytics India Magazine. (2023). Borne Out Of Hackathons. https://analyticsindiamag.com/ai-trends/borne-out-of-hackathons/
[3] Wikipedia. (n.d.). Hackathon: Origin and History. https://en.wikipedia.org/wiki/Hackathon#Origin_and_history
[4] LinkedIn. (2024). This year marked my third annual participation in Microsoft’s Global…. https://www.linkedin.com/posts/clare-ashforth_this-year-marked-my-third-annual-participation-activity-7247636808119775233-yev-
[5] Glasp. (n.d.). Chris Dixon’s Quotes. https://glasp.co/quotes/chris-dixon
[6] ODaily. (2024). Naija HackAtom Hackathon Recap. https://www.odaily.news/en/post/5203212
[7] Solana. (2021). Meet the winners of the Riptide hackathon - Solana. https://solana.com/news/riptide-hackathon-winners-solana
[8] DoraHacks. (n.d.). BNB Grant DAO - DoraHacks. https://dorahacks.io/bnb
[9] Cointelegraph. (2021). From Hackathon Project to DeFi Powerhouse: AMA with 1inch Network. https://cointelegraph.com/news/from-hackathon-project-to-defi-powerhouse-ama-with-1inch-network
[10] Gemini. (2022). How Does STEPN Work? GST and GMT Token Rewards. https://www.gemini.com/cryptopedia/stepn-nft-sneakers-gmt-token-gst-crypto-move-to-earn-m2e
[11] CoinDesk. (2022). Inside DoraHacks: The Open Source Bazaar Empowering Web3 Innovations. https://www.coindesk.com/sponsored-content/inside-dorahacks-the-open-source-bazaar-empowering-web3-innovations
[12] LinkedIn. (n.d.). DoraHacks. https://www.linkedin.com/company/dorahacks
[13] Blockworks. (2022). Web3 Hackathon Incubator DoraHacks Nabs $20M From FTX, Liberty City. https://blockworks.co/news/web3-hackathon-incubator-dorahacks-nabs-20m-from-ftx-liberty-city
[14] Followin. (2024). BUIDL AI: The future of Hackathon, a new engine for global open source technology. https://followin.io/en/feed/16892627
[15] Coinbase. (2024). Coinbase Hosts Its First AI Hackathon: Bringing the San Francisco Developer Community Onchain. https://www.coinbase.com/developer-platform/discover/launches/Coinbase-AI-hackathon
[16] Graham, P. (2004). Hackers & Painters. https://ics.uci.edu/~pattis/common/handouts/hackerspainters.pdf
[17] Himalayas. (n.d.). DoraHacks hiring Research Engineer – BUIDL AI. https://himalayas.app/companies/dorahacks/jobs/research-engineer-buidl-ai
[18] X. (n.d.). DoraHacks. https://x.com/dorahacks?lang=en

@ 3bf0c63f:aefa459d

Personagens de jogos e símbolos

A sensação de "ser" um personagem em um jogo ou uma brincadeira talvez seja o mais próximo que eu tenha conseguido chegar do entendimento de um símbolo religioso.

A hóstia consagrada é, segundo a religião, o corpo de Cristo, mas nossa mente moderna só consegue concebê-la como sendo uma representação do corpo de Cristo. Da mesma forma outras culturas e outras religiões têm símbolos parecidos, inclusive nos quais o próprio participante do ritual faz o papel de um deus ou de qualquer coisa parecida.

"Faz o papel" é de novo a interpretação da mente moderna. O sujeito ali é a coisa, mas ele ao mesmo tempo que é também sabe que não é, que continua sendo ele mesmo.

Nos jogos de videogame e brincadeiras infantis em que se encarna um personagem o jogador é o personagem. não se diz, entre os jogadores, que alguém está "encenando", mas que ele é e pronto. nem há outra denominação ou outro verbo. No máximo "encarnando", mas já aí já é vocabulário jornalístico feito para facilitar a compreensão de quem está de fora do jogo.

@ 3bf0c63f:aefa459d

bolt12 problems

• clients can't programatically build new offers by changing a path or query params (services like zbd.gg or lnurl-pay.me won't work)
• impossible to use in a load-balanced custodian way -- since offers would have to be pregenerated and tied to a specific lightning node.
• the existence of fiat currency fields makes it so wallets have to fetch exchange rates from somewhere on the internet (or offer a bad user experience), using HTTP which hurts user privacy.
• the vendor field is misleading, can be phished very easily, not as safe as a domain name.
• onion messages are an improvement over fake HTLC-based payments as a way of transmitting data, for sure. but we must decide if they are (i) suitable for transmitting all kinds of data over the internet, a replacement for tor; or (ii) not something that will scale well or on which we can count on for the future. if there was proper incentivization for data transmission it could end up being (i), the holy grail of p2p communication over the internet, but that is a very hard problem to solve and not guaranteed to yield the desired scalability results. since not even hints of attempting to solve that are being made, it's safer to conclude it is (ii).

bolt12 limitations

• not flexible enough. there are some interesting fields defined in the spec, but who gets to add more fields later if necessary? very unclear.
• services can't return any actionable data to the users who paid for something. it's unclear how business can be conducted without an extra communication channel.

bolt12 illusions

• recurring payments is not really solved, it is just a spec that defines intervals. the actual implementation must still be done by each wallet and service. the recurring payment cannot be enforced, the wallet must still initiate the payment. even if the wallet is evil and is willing to initiate a payment without the user knowing it still needs to have funds, channels, be online, connected etc., so it's not as if the services could rely on the payments being delivered in time.
• people seem to think it will enable pushing payments to mobile wallets, which it does not and cannot.
• there is a confusion of contexts: it looks like offers are superior to lnurl-pay, for example, because they don't require domain names. domain names, though, are common and well-established among internet services and stores, because these services have websites, so this is not really an issue. it is an issue, though, for people that want to receive payments in their homes. for these, indeed, bolt12 offers a superior solution -- but at the same time bolt12 seems to be selling itself as a tool for merchants and service providers when it includes and highlights features as recurring payments and refunds.
• the privacy gains for the receiver that are promoted as being part of bolt12 in fact come from a separate proposal, blinded paths, which should work for all normal lightning payments and indeed are a very nice solution. they are (or at least were, and should be) independent from the bolt12 proposal. a separate proposal, which can be (and already is being) used right now, also improves privacy for the receiver very much anway, it's called trampoline routing.

@ a012dc82:6458a70d

Argentina's journey through economic turmoil has been long and fraught with challenges. The country has grappled with inflation, debt, and a fragile economic structure that has left policymakers searching for solutions. In this context, President Javier Milei's introduction of the "Ley Ómnibus" represented a bold step towards addressing these systemic issues. The reform package was not just a set of isolated measures but a comprehensive plan aimed at overhauling the Argentine economy and social framework. The intention was to create a more robust, free, and prosperous Argentina, where economic freedoms could lead to broader social benefits.

The "Ley Ómnibus" was ambitious in its scope, covering a wide range of areas from tax reform to social policies, aiming to stimulate economic growth, reduce bureaucratic red tape, and enhance the overall quality of life for Argentines. This package was seen as a critical move to reset the economic compass of the country, aiming to attract foreign investment, boost local industry, and provide a clearer, more stable environment for businesses and individuals alike. However, such sweeping reforms were bound to encounter resistance, particularly when they touched upon sensitive areas like taxation and digital assets.

Table of Contents

• The Crypto Tax Proposal: Initial Considerations

• Public Backlash and Strategic Withdrawal

• The Rationale Behind Dropping Crypto Taxes

• Implications for Crypto Investors and the Market

• Milei's Political Strategy and Future Prospects

• Conclusion

• FAQs

The Crypto Tax Proposal: Initial Considerations

Within the vast array of proposals in the Ley Ómnibus, the crypto tax stood out due to its novelty and the growing interest in digital currencies within Argentina. The country had seen a surge in cryptocurrency adoption, driven by factors such as high inflation rates and currency controls that made traditional financial systems less attractive. Cryptocurrencies offered an alternative for savings, investment, and transactions, leading to a burgeoning crypto economy.

The initial rationale behind proposing a crypto tax was multifaceted. On one hand, it aimed to bring Argentina in line with global trends where countries are increasingly seeking to regulate and tax digital currencies. On the other hand, it was seen as a potential new revenue stream for the government, which was desperately seeking funds to address its fiscal deficits. The proposal also intended to bring transparency to a sector that is often criticized for its opacity, making it easier to combat fraud, money laundering, and other illicit activities associated with cryptocurrencies.

However, the proposal was not just about regulation and revenue. It was also a litmus test for Argentina's approach to innovation and digital transformation. How the government handled this issue would signal its stance towards new technologies and economic paradigms, which are increasingly dominated by digital assets and fintech innovations.

Public Backlash and Strategic Withdrawal

The backlash against the proposed crypto taxes was swift and significant. The crypto community in Argentina, which had been flourishing in an environment of relative freedom, saw the tax as a direct threat to its growth and viability. But the discontent went beyond the crypto enthusiasts; the general public, already burdened by high taxes and economic instability, viewed the proposal as yet another financial strain.

The protests and debates that ensued highlighted a broader discontent with the government's approach to economic management. Many Argentines felt that the focus should be on fixing the fundamental issues plaguing the economy, such as inflation and corruption, rather than imposing new taxes. The crypto tax became a symbol of the government's perceived detachment from the real concerns of its citizens.

In this heated atmosphere, President Milei's decision to withdraw the crypto tax proposal from the Ley Ómnibus was not just a tactical retreat; it was a necessary move to quell the growing unrest and focus on more pressing economic reforms. This decision underscored the complexities of governing in a highly polarized environment and the need for a more nuanced approach to policy-making, especially when dealing with emerging technologies and markets.

The Rationale Behind Dropping Crypto Taxes

The decision to drop the crypto tax from the omnibus reform package was not taken lightly. It was a recognition of the crypto sector's unique dynamics and the government's limitations in effectively regulating and taxing this space without stifling innovation. The move also reflected a broader understanding of the economic landscape, where rapid development and legislative efficiency were deemed more crucial than ever.

By removing the contentious clauses, the government aimed to streamline the passage of the Ley Ómnibus, ensuring that other, less controversial, reforms could be implemented swiftly. This strategic pivot was also a nod to the global debate on how best to integrate cryptocurrencies into national economies. Argentina's government recognized that a more cautious and informed approach was necessary, one that could balance the need for regulation with the desire to foster a thriving digital economy.

Furthermore, the withdrawal of the crypto tax proposal can be seen as an acknowledgment of the power of public opinion and the crypto community's growing influence. It highlighted the need for governments to engage with stakeholders and understand the implications of new technologies before rushing to regulate them.

Implications for Crypto Investors and the Market

The removal of the crypto tax proposal has had immediate and significant implications for the Argentine crypto market. For investors, the decision has provided a reprieve from the uncertainty that had clouded the sector, allowing them to breathe a sigh of relief and continue their activities without the looming threat of new taxes. This has helped sustain the momentum of the crypto market in Argentina, which is seen as a vital component of the country's digital transformation and economic diversification.

However, the situation remains complex and fluid. The government's stance on cryptocurrencies is still evolving, and future regulations could impact the market in unforeseen ways. Investors are now more aware of the need to stay informed and engaged with regulatory developments, understanding that the legal landscape for digital currencies is still being shaped.

The episode has also highlighted the broader challenges facing the Argentine economy, including the need for comprehensive tax reform and the creation of a more conducive environment for technological innovation and investment. The crypto market's response to the government's actions reflects the delicate balance between regulation and growth, a balance that will be crucial for Argentina's economic future.

Milei's Political Strategy and Future Prospects

President Milei's handling of the crypto tax controversy reveals much about his political strategy and vision for Argentina. By withdrawing the proposal, he demonstrated a willingness to listen to public concerns and adapt his policies accordingly. This flexibility could be a key asset as he navigates the complex landscape of Argentine politics and governance.

The episode also offers insights into the potential future direction of Milei's administration. The focus on economic reforms, coupled with a pragmatic approach to contentious issues, suggests a leadership style that prioritizes economic stability and growth over ideological purity. This could bode well for Argentina's future, particularly if Milei can harness the energy and innovation of the digital economy as part of his broader reform agenda.

However, the challenges ahead are significant. The Ley Ómnibus is just one part of a larger puzzle, and Milei's ability to implement comprehensive reforms will be tested in the coming months and years. The crypto tax saga has shown that while change is possible, it requires careful negotiation, stakeholder engagement, and a clear understanding of the economic and social landscape.

Conclusion

The story of Argentina's crypto tax proposal is a microcosm of the broader challenges facing the country as it seeks to reform its economy and society. It highlights the tensions between innovation and regulation, the importance of public opinion, and the complexities of governance in a rapidly changing world.

As Argentina moves forward, the lessons learned from this episode will be invaluable. The need for clear, informed, and inclusive policy-making has never been greater, particularly as the country navigates the uncertainties of the digital age.

FAQs

What is the Ley Ómnibus? The Ley Ómnibus, formally known as the "Law of Bases and Starting Points for the Freedom of Argentines," is a comprehensive reform package introduced by President Javier Milei. It aims to address various economic, social, and administrative issues in Argentina, aiming to stimulate growth, reduce bureaucracy, and improve the overall quality of life.

Why were crypto taxes proposed in Argentina? Crypto taxes were proposed as part of the Ley Ómnibus to broaden the tax base, align with global trends of regulating digital currencies, and generate additional revenue for the government. They were also intended to bring more transparency to the cryptocurrency sector in Argentina.

Why were the proposed crypto taxes withdrawn? The proposed crypto taxes were withdrawn due to significant public backlash and concerns that they would stifle innovation and economic freedom in the burgeoning crypto market. The decision was also influenced by the government's priority to ensure the swift passage of other reforms within the Ley Ómnibus.

What does the withdrawal of crypto taxes mean for investors? The withdrawal means that, for now, crypto investors in Argentina will not face additional taxes specifically targeting their cryptocurrency holdings or transactions. However, selling large amounts of cryptocurrency at a profit will still be subject to income tax.

That's all for today

If you want more, be sure to follow us on:

NOSTR: croxroad@getalby.com

X: @croxroadnewsco

Instagram: @croxroadnews.co/

Youtube: @thebitcoinlibertarian

Store: https://croxroad.store

Subscribe to CROX ROAD Bitcoin Only Daily Newsletter

https://www.croxroad.co/subscribe

Get Orange Pill App And Connect With Bitcoiners In Your Area. Stack Friends Who Stack Sats link: https://signup.theorangepillapp.com/opa/croxroad

Buy Bitcoin Books At Konsensus Network Store. 10% Discount With Code “21croxroad” link: https://bitcoinbook.shop?ref=21croxroad

DISCLAIMER: None of this is financial advice. This newsletter is strictly educational and is not investment advice or a solicitation to buy or sell any assets or to make any financial decisions. Please be careful and do your own research.

@ 04c915da:3dfbecc9

Bitcoin has always been rooted in freedom and resistance to authority. I get that many of you are conflicted about the US Government stacking but by design we cannot stop anyone from using bitcoin. Many have asked me for my thoughts on the matter, so let’s rip it.

Concern

One of the most glaring issues with the strategic bitcoin reserve is its foundation, built on stolen bitcoin. For those of us who value private property this is an obvious betrayal of our core principles. Rather than proof of work, the bitcoin that seeds this reserve has been taken by force. The US Government should return the bitcoin stolen from Bitfinex and the Silk Road.

Usually stolen bitcoin for the reserve creates a perverse incentive. If governments see a bitcoin as a valuable asset, they will ramp up efforts to confiscate more bitcoin. The precedent is a major concern, and I stand strongly against it, but it should be also noted that governments were already seizing coin before the reserve so this is not really a change in policy.

Ideally all seized bitcoin should be burned, by law. This would align incentives properly and make it less likely for the government to actively increase coin seizures. Due to the truly scarce properties of bitcoin, all burned bitcoin helps existing holders through increased purchasing power regardless. This change would be unlikely but those of us in policy circles should push for it regardless. It would be best case scenario for American bitcoiners and would create a strong foundation for the next century of American leadership.

Optimism

The entire point of bitcoin is that we can spend or save it without permission. That said, it is a massive benefit to not have one of the strongest governments in human history actively trying to ruin our lives.

Since the beginning, bitcoiners have faced horrible regulatory trends. KYC, surveillance, and legal cases have made using bitcoin and building bitcoin businesses incredibly difficult. It is incredibly important to note that over the past year that trend has reversed for the first time in a decade. A strategic bitcoin reserve is a key driver of this shift. By holding bitcoin, the strongest government in the world has signaled that it is not just a fringe technology but rather truly valuable, legitimate, and worth stacking.

This alignment of incentives changes everything. The US Government stacking proves bitcoin’s worth. The resulting purchasing power appreciation helps all of us who are holding coin and as bitcoin succeeds our government receives direct benefit. A beautiful positive feedback loop.

Realism

We are trending in the right direction. A strategic bitcoin reserve is a sign that the state sees bitcoin as an asset worth embracing rather than destroying. That said, there is a lot of work left to be done. We cannot be lulled into complacency, the time to push forward is now, and we cannot take our foot off the gas. We have a seat at the table for the first time ever. Let's make it worth it.

We must protect the right to free usage of bitcoin and other digital technologies. Freedom in the digital age must be taken and defended, through both technical and political avenues. Multiple privacy focused developers are facing long jail sentences for building tools that protect our freedom. These cases are not just legal battles. They are attacks on the soul of bitcoin. We need to rally behind them, fight for their freedom, and ensure the ethos of bitcoin survives this new era of government interest. The strategic reserve is a step in the right direction, but it is up to us to hold the line and shape the future.

@ d34e832d:383f78d0

Practical Privacy and Secure Communications

---

1. Bootable privacy operating systems—Tails, Qubes OS, and Whonix****

This Idea explores the technical deployment of bootable privacy operating systems—Tails, Qubes OS, and Whonix—for individuals and organizations seeking to enhance operational security (OpSec). These systems provide different layers of isolation, anonymity, and confidentiality, critical for cryptographic operations, Bitcoin custody, journalistic integrity, whistleblowing, and sensitive communications. The paper outlines optimal use cases, system requirements, technical architecture, and recommended operational workflows for each OS.

---

2. Running An Operating System

In a digital world where surveillance, metadata leakage, and sophisticated threat models are realities, bootable privacy OSs offer critical mitigation strategies. By running an operating system from a USB, DVD, or external drive—and often entirely in RAM—users can minimize the footprint left on host hardware, dramatically enhancing privacy.

This document details Tails, Qubes OS, and Whonix: three leading open-source projects addressing different aspects of operational security.

---

3. Technical Overview of Systems

| OS | Focus | Main Feature | Threat Model | |------------|---------------------------|-----------------------------------------------|--------------------------------| | Tails | Anonymity & Ephemerality | Runs entirely from RAM; routes traffic via Tor | For activists, journalists, Bitcoin users | | Qubes OS | Security through Compartmentalization | Hardware-level isolation via Xen hypervisor | Defense against malware, APTs, insider threats | | Whonix | Anonymity over Tor Networks | Split-Gateway Architecture (Whonix-Gateway & Whonix-Workstation) | For researchers, Bitcoin node operators, privacy advocates |

---

4. System Requirements

4.1 Tails

• RAM: Minimum 2 GB (4 GB recommended)
• CPU: x86_64 (Intel or AMD)
• Storage: 8GB+ USB stick (optional persistent storage)

4.2 Qubes OS

• RAM: 16 GB minimum
• CPU: Intel VT-x or AMD-V support required
• Storage: 256 GB SSD recommended
• GPU: Minimal compatibility (no Nvidia proprietary driver support)

4.3 Whonix

• Platform: VirtualBox/KVM Host (Linux, Windows, Mac)
• RAM: 4 GB minimum (8 GB recommended)
• Storage: 100 GB suggested for optimal performance

---

5. Deployment Models

| Model | Description | Recommended OS | |--------------------------|-----------------------------------|------------------------------| | USB-Only Boot | No installation on disk; ephemeral use | Tails | | Hardened Laptop | Full disk installation with encryption | Qubes OS | | Virtualized Lab | VMs on hardened workstation | Whonix Workstation + Gateway |

---

6. Operational Security Advantages

| OS | Key Advantages | |------------|----------------------------------------------------------------------------------------------------| | Tails | Memory wipe at shutdown, built-in Tor Browser, persistent volume encryption (LUKS) | | Qubes OS | Compartmentalized VMs for work, browsing, Bitcoin keys; TemplateVMs reduce attack surface | | Whonix | IP address leaks prevented even if the workstation is compromised; full Tor network integration |

---

7. Threat Model Coverage

| Threat Category | Tails | Qubes OS | Whonix | |----------------------------|-----------------|------------------|------------------| | Disk Forensics | ✅ (RAM-only) | ✅ (with disk encryption) | ✅ (VM separation) | | Malware Containment | ❌ | ✅ (strong) | ✅ (via VMs) | | Network Surveillance | ✅ (Tor enforced) | Partial (needs VPN/Tor setup) | ✅ (Tor Gateway) | | Hardware-Level Attacks | ❌ | ❌ | ❌ |

---

8. Use Cases

• Bitcoin Cold Storage and Key Signing (Tails)
• Boot Tails offline for air-gapped Bitcoin signing.
• Private Software Development (Qubes)
• Use separate VMs for coding, browsing, and Git commits.
• Anonymous Research (Whonix)
• Surf hidden services (.onion) without IP leak risk.
• Secure Communications (All)
• Use encrypted messaging apps (Session, XMPP, Matrix) without metadata exposure.

---

9. Challenges and Mitigations

| Challenge | Mitigation | |---------------------|---------------------------------------------| | Hardware Incompatibility | Validate device compatibility pre-deployment (esp. for Qubes) | | Tor Exit Node Surveillance | Use onion services or bridge relays (Tails, Whonix) | | USB Persistence Risks | Always encrypt persistent volumes (Tails) | | Hypervisor Bugs (Qubes) | Regular OS and TemplateVM updates |

Here’s a fully original technical whitepaper version of your request, rewritten while keeping the important technical ideas intact but upgrading structure, language, and precision.

Executive Summary

In a world where digital surveillance and privacy threats are escalating, bootable privacy operating systems offer a critical solution for at-risk individuals. Systems like Tails, Qubes OS, and Whonix provide strong, portable security by isolating user activities from compromised or untrusted hardware. This paper explores their architectures, security models, and real-world applications.

---

1. To Recap

Bootable privacy-centric operating systems are designed to protect users from forensic analysis, digital tracking, and unauthorized access. By booting from an external USB drive or DVD and operating independently from the host machine's internal storage, they minimize digital footprints and maximize operational security (OpSec).

This paper provides an in-depth technical analysis of: - Tails (The Amnesic Incognito Live System) - Qubes OS (Security through Compartmentalization) - Whonix (Anonymity via Tor Isolation)

Each system’s strengths, limitations, use cases, and installation methods are explored in detail.

---

2. Technical Overview of Systems

2.1 Tails (The Amnesic Incognito Live System)

Architecture:
- Linux-based Debian derivative. - Boots from USB/DVD, uses RAM exclusively unless persistent storage is manually enabled. - Routes all network traffic through Tor. - Designed to leave no trace unless explicitly configured otherwise.

Key Features:
- Memory erasure on shutdown. - Pre-installed secure applications: Tor Browser, KeePassXC, OnionShare. - Persistent storage available but encrypted and isolated.

Limitations:
- Limited hardware compatibility (especially Wi-Fi drivers). - No support for mobile OS platforms. - ISP visibility to Tor network usage unless bridges are configured.

---

2.2 Qubes OS

Architecture:
- Xen-based hypervisor model. - Security through compartmentalization: distinct "qubes" (virtual machines) isolate tasks and domains (work, personal, banking, etc.). - Networking and USB stacks run in restricted VMs to prevent direct device access.

Key Features:
- Template-based management for efficient updates. - Secure Copy (Qubes RPC) for data movement without exposing full disks. - Integrated Whonix templates for anonymous browsing.

Limitations:
- Requires significant hardware resources (RAM and CPU). - Limited hardware compatibility (strict requirements for virtualization support: VT-d/IOMMU).

---

2.3 Whonix

Architecture:
- Debian-based dual VM system. - One VM (Gateway) routes all traffic through Tor; the second VM (Workstation) is fully isolated from the physical network. - Can be run on top of Qubes OS, VirtualBox, or KVM.

Key Features:
- Complete traffic isolation at the system level. - Strong protections against IP leaks (fails closed if Tor is inaccessible). - Advanced metadata obfuscation options.

Limitations:
- High learning curve for proper configuration. - Heavy reliance on Tor can introduce performance bottlenecks.

---

3. Comparative Analysis

| Feature | Tails | Qubes OS | Whonix | |:--------|:------|:---------|:-------| | Anonymity Focus | High | Medium | High | | System Isolation | Medium | Very High | High | | Persistence | Optional | Full | Optional | | Hardware Requirements | Low | High | Medium | | Learning Curve | Low | High | Medium | | Internet Privacy | Mandatory Tor | Optional Tor | Mandatory Tor |

---

4. Use Cases

| Scenario | Recommended System | |:---------|:--------------------| | Emergency secure browsing | Tails | | Full system compartmentalization | Qubes OS | | Anonymous operations with no leaks | Whonix | | Activist communications from hostile regions | Tails or Whonix | | Secure long-term project management | Qubes OS |

---

5. Installation Overview

5.1 Hardware Requirements

• Tails: Minimum 2GB RAM, USB 2.0 or higher, Intel or AMD x86-64 processor.
• Qubes OS: Minimum 16GB RAM, VT-d/IOMMU virtualization support, SSD storage.
• Whonix: Runs inside VirtualBox or Qubes; requires host compatibility.

5.2 Setup Instructions

Tails: 1. Download latest ISO from tails.net. 2. Verify signature (GPG or in-browser). 3. Use balenaEtcher or dd to flash onto USB. 4. Boot from USB, configure Persistent Storage if necessary.

Qubes OS: 1. Download ISO from qubes-os.org. 2. Verify using PGP signatures. 3. Flash to USB or DVD. 4. Boot and install onto SSD with LUKS encryption enabled.

Whonix: 1. Download both Gateway and Workstation VMs from whonix.org. 2. Import into VirtualBox or a compatible hypervisor. 3. Configure VMs to only communicate through the Gateway.

---

6. Security Considerations

• Tails: Physical compromise of the USB stick is a risk. Use hidden storage if necessary.
• Qubes OS: Qubes is only as secure as its weakest compartment; misconfigured VMs can leak data.
• Whonix: Full reliance on Tor can reveal usage patterns if used carelessly.

Best Practices: - Always verify downloads via GPG. - Use a dedicated, non-personal device where possible. - Utilize Tor bridges if operating under oppressive regimes. - Practice OPSEC consistently—compartmentalization, metadata removal, anonymous communications.

---

7. Consider

Bootable privacy operating systems represent a critical defense against modern surveillance and oppression. Whether for emergency browsing, long-term anonymous operations, or full-stack digital compartmentalization, solutions like Tails, Qubes OS, and Whonix empower users to reclaim their privacy.

When deployed thoughtfully—with an understanding of each system’s capabilities and risks—these tools can provide an exceptional layer of protection for journalists, activists, security professionals, and everyday users alike.

10. Example: Secure Bitcoin Signing Workflow with Tails

1. Boot Tails from USB.
2. Disconnect from the network.
3. Generate Bitcoin private key or sign transaction using Electrum.
4. Save signed transaction to encrypted USB drive.
5. Shut down to wipe RAM completely.
6. Broadcast transaction from a separate, non-sensitive machine.

This prevents key exposure to malware, man-in-the-middle attacks, and disk forensic analysis.

---

11. Consider

Bootable privacy operating systems like Tails, Qubes OS, and Whonix offer robust, practical strategies for improving operational security across a wide spectrum of use cases—from Bitcoin custody to anonymous journalism. Their open-source nature, focus on minimizing digital footprints, and mature security architectures make them foundational tools for modern privacy workflows.

Choosing the appropriate OS depends on the specific threat model, hardware available, and user needs. Proper training and discipline remain crucial to maintain the security these systems enable.

---

Appendices

A. Download Links

• Tails Official Site
• Qubes OS Official Site
• Whonix Official Site

B. Further Reading

• "The Qubes OS Architecture" Whitepaper
• "Operational Security and Bitcoin" by Matt Odell
• "Tor and the Darknet: Separating Myth from Reality" by EFF

@ 3bf0c63f:aefa459d

WelcomeBot

The first bot ever created for Trello.

It invited to a public board automatically anyone who commented on a card he was added to.

• https://github.com/fiatjaf/welcomebot
• https://trello.com/welcomebot

@ 3bf0c63f:aefa459d

Sol e Terra

A Terra não gira em torno do Sol. Tudo depende do ponto de referência e não existe um ponto de referência absoluto. Só é melhor dizer que a Terra gira em torno do Sol porque há outros planetas fazendo movimentos análogos e aí fica mais fácil para todo mundo entender os movimentos tomando o Sol como ponto de referência.

@ 3bf0c63f:aefa459d

A list of things artificial intelligence is not doing

If AI is so good why can't it:

• write good glue code that wraps a documented HTTP API?
• make good translations using available books and respective published translations?
• extract meaningful and relevant numbers from news articles?
• write mathematical models that fit perfectly to available data better than any human?
• play videogames without cheating (i.e. simulating human vision, attention and click speed)?
• turn pure HTML pages into pretty designs by generating CSS
• predict the weather
• calculate building foundations
• determine stock values of companies from publicly available numbers
• smartly and automatically test software to uncover bugs before releases
• predict sports matches from the ball and the players' movement on the screen
• continuously improve niche/local search indexes based on user input and and reaction to results
• control traffic lights
• predict sports matches from news articles, and teams and players' history

This was posted first on Twitter.

@ d34e832d:383f78d0

A Secure, Compact, and Cost-Effective Offline Key Management System

---

1. Idea

This idea presents a cryptographic key generation appliance built on the Nookbox G9, a compact 1U mini NAS solution. Designed to be a dedicated air-gapped or offline-first device, this system enables the secure generation and handling of RSA, ECDSA, and Ed25519 key pairs. By leveraging the Nookbox G9's small form factor, NVMe storage, and Linux compatibility, we outline a practical method for individuals and organizations to deploy secure, reproducible, and auditable cryptographic processes without relying on cloud or always-connected environments.

---

2. Minimization Of Trust

In an era where cryptographic operations underpin everything from Bitcoin transactions to secure messaging, generating keys in a trust-minimized environment is critical. Cloud-based solutions or general-purpose desktops expose key material to increased risk. This project defines a dedicated hardware appliance for cryptographic key generation using Free and Open Source Software (FOSS) and a tightly scoped threat model.

---

3. Hardware Overview: Nookbox G9

| Feature | Specification | |-----------------------|----------------------------------------------------| | Form Factor | 1U Mini NAS | | Storage Capacity | Up to 8TB via 4 × 2TB M.2 NVMe SSDs | | PCIe Interface | Each M.2 slot uses PCIe Gen 3x2 | | Networking | Dual 2.5 Gigabit Ethernet | | Cooling | Passive cooling (requires modification for load) | | Operating System | Windows 11 pre-installed; compatible with Linux |

This hardware is chosen for its compact size, multiple SSD support, and efficient power consumption (~11W idle on Linux). It fits easily into a secure rack cabinet and can run entirely offline.

---

4. System Configuration

4.1 OS & Software Stack

We recommend wiping Windows and installing:

• OS: Ubuntu 24.10 LTS or Debian 12
• Key Tools:
• gnupg (for GPG, RSA, and ECC)
• age or rage (for modern encryption)
• openssl (general-purpose cryptographic tool)
• ssh-keygen (for Ed25519 or RSA SSH keys)
• vault (optional: HashiCorp Vault for managing key secrets)
• pwgen / diceware (for secure passphrase generation)

4.2 Storage Layout

• Drive 1 (System): Ubuntu 24.10 with encrypted LUKS partition
• Drive 2 (Key Store): Encrypted Veracrypt volume for keys and secrets
• Drive 3 (Backup): Offline encrypted backup (mirrored or rotated)
• Drive 4 (Logs & Audit): System logs, GPG public keyring, transparency records

---

5. Security Principles

• Air-Gapping: Device operates disconnected from the internet during key generation.
• FOSS Only: All software used is open-source and auditable.
• No TPM/Closed Firmware Dependencies: BIOS settings disable Intel ME, TPM, and Secure Boot.
• Tamper Evidence: Physical access logs and optional USB kill switch setup.
• Transparency: Generation scripts stored on device, along with SHA256 of all outputs.

---

6. Workflow: Generating Keypairs

Example: Generating an Ed25519 GPG Key

```bash gpg --full-generate-key

Choose ECC > Curve: Ed25519

Set expiration, user ID, passphrase

```

Backup public and private keys:

bash gpg --armor --export-secret-keys [keyID] > private.asc gpg --armor --export [keyID] > public.asc sha256sum *.asc > hashes.txt

Store on encrypted volume and create a printed copy (QR or hex dump) for physical backup.

---

7. Performance Notes

While limited to PCIe Gen 3x2 (approx. 1.6 GB/s per slot), the speed is more than sufficient for key generation workloads. The bottleneck is not IO-bound but entropy-limited and CPU-bound. In benchmarks:

• RSA 4096 generation: ~2–3 seconds
• Ed25519 generation: <1 second
• ZFS RAID-Z writes (if used): ~250MB/s due to 2.5Gbps NIC ceiling

Thermal throttling may occur under extended loads without cooling mods. A third-party aluminum heatsink resolves this.

---

8. Use Cases

• Bitcoin Cold Storage (xprv/xpub, seed phrases)
• SSH Key Infrastructure (Ed25519 key signing for orgs)
• PGP Trust Anchor (for a Web of Trust or private PKI)
• Certificate Authority (offline root key handling)
• Digital Notary Service (hash-based time-stamping)

---

9. Recommendations & Improvements

| Area | Improvement | |-------------|--------------------------------------| | Cooling | Add copper heatsinks + airflow mod | | Power | Use UPS + power filter for stability | | Boot | Use full-disk encryption with Yubikey unlock | | Expansion | Use one SSD for keybase-style append-only logs | | Chassis | Install into a tamper-evident case with RFID tracking |

---

10. Consider

The Nookbox G9 offers a compact, energy-efficient platform for creating a secure cryptographic key generation appliance. With minor thermal enhancements and a strict FOSS policy, it becomes a reliable workstation for cryptographers, developers, and Bitcoin self-custodians. Its support for multiple encrypted SSDs, air-gapped operation, and Linux flexibility make it a modern alternative to enterprise HSMs—without the cost or vendor lock-in.

---

A. Key Software Versions

• GnuPG 2.4.x
• OpenSSL 3.x
• Ubuntu 24.10
• Veracrypt 1.26+

B. System Commands (Setup)

bash sudo apt install gnupg2 openssl age veracrypt sudo cryptsetup luksFormat /dev/nvme1n1

C. Resources

• Veracrypt Documentation
• GPG Manual
• Ed25519 Explained

The Nookbox G9 epitomizes a compact yet sophisticated energy-efficient computational architecture, meticulously designed to serve as a secure cryptographic key generation appliance. By integrating minor yet impactful thermal enhancements, it ensures optimal performance stability while adhering to a stringent Free and Open Source Software (FOSS) policy, thereby positioning itself as a reliable workstation specifically tailored for cryptographers, software developers, and individuals engaged in Bitcoin self-custody. Its capability to support multiple encrypted Solid State Drives (SSDs) facilitates an augmented data security framework, while the air-gapped operational feature significantly enhances its resilience against potential cyber threats. Furthermore, the inherent flexibility of Linux operating systems not only furnishes an adaptable environment for various cryptographic applications but also serves as a compelling modern alternative to conventional enterprise Hardware Security Modules (HSMs), ultimately bypassing the prohibitive costs and vendor lock-in typically associated with such proprietary solutions.

Further Tools

🔧 Recommended SSDs and Tools (Amazon)

1. Kingston A400 240GB SSD – SATA 3 2.5"
   https://a.co/d/41esjYL

2. Samsung 970 EVO Plus 2TB NVMe M.2 SSD – Gen 3
   https://a.co/d/6EMVAN1

3. Crucial P5 Plus 1TB PCIe Gen4 NVMe M.2 SSD
   https://a.co/d/hQx50Cq

4. WD Blue SN570 1TB NVMe SSD – PCIe Gen 3
   https://a.co/d/j2zSDCJ

5. Sabrent Rocket Q 2TB NVMe SSD – QLC NAND
   https://a.co/d/325Og2K

6. Thermalright M.2 SSD Heatsink Kit
   https://a.co/d/0IYH3nK

7. ORICO M.2 NVMe SSD Enclosure – USB 3.2 Gen2
   https://a.co/d/aEwQmih

---

Product Links (Amazon)

1. Thermal Heatsink for M.2 SSDs (Must-have for stress and cooling)
   https://a.co/d/43B1F3t

2. Nookbox G9 – Mini NAS
   https://a.co/d/3dswvGZ

3. Alternative 1: Possibly related cooling or SSD gear
   https://a.co/d/c0Eodm3

4. Alternative 2: Possibly related NAS accessories or SSDs
   https://a.co/d/9gWeqDr

---

Benchmark Results (Geekbench)

1. GMKtec G9 Geekbench CPU Score #1
   https://browser.geekbench.com/v6/cpu/11471182

2. GMKtec G9 Geekbench CPU Score #2
   https://browser.geekbench.com/v6/cpu/11470130

3. GMKtec Geekbench User Profile
   https://browser.geekbench.com/user/446940

---

🛠️ DIY & Fix Resource

• How-Fixit – PC Repair Guides and Tutorials
  https://www.how-fixit.com/

@ b8a9df82:6ab5cbbd

Last week at Bitcoin Investment Week in New York City, hosted by Anthony Pompliano, Jack Mallers walked in wearing sneakers and a T-shirt, casually dropping, “Man… I hate politics.”

That was it. That was the moment I felt aligned again. That’s the energy I came for. No suits. No corporate jargon. Just a guy who gets it—who cares about people, bringing Bitcoin-powered payments to the masses and making sure people can actually use it.

His presence was a reminder of why we’re here in the first place. And his words—“I hate politics”—were a breath of fresh air.

Now, don’t get me wrong. Anthony was a fantastic host. His ability to mix wittiness, playfulness, and seriousness made him an entertaining moderator. But this week was unlike anything I’ve ever experienced in the Bitcoin ecosystem.

One of the biggest letdowns was the lack of interaction. No real Q&A sessions, no direct engagement, no real discussions. Just one fireside chat after another.

And sure, I get it—people love to hear themselves talk. But where were the questions? The critical debates? The chance for the audience to actually participate?

I’m used to Bitcoin meetups and conferences where you walk away with new ideas, new friends, and maybe even a new project to contribute to. Here, it was more like sitting in an expensive lecture hall, watching a lineup of speakers tell us things we already know.

A different vibe—and not in a good way

Over the past few months, I’ve attended nearly ten Bitcoin conferences, each leaving me feeling uplifted, inspired, and ready to take action. But this? This felt different. And not in a good way.

If this had been my first Bitcoin event, I might have walked away questioning whether I even belonged here. It wasn’t Prague. It wasn’t Riga. It wasn’t the buzzing, grassroots, pleb-filled gatherings I had grown to love. Instead, it felt more like a Wall Street networking event disguised as a Bitcoin conference.

Maybe it was the suits.

Or the fact that I was sitting in a room full of investors who have no problem dropping $1,000+ on a ticket.

Or that it reminded me way too much of my former life—working as a manager in London’s real estate industry, navigating boardrooms full of finance guys in polished shoes, talking about “assets under management.”

Bitcoin isn’t just an investment thesis. It’s a revolution. A movement. And yet, at times during this week, I felt like I was back in my fiat past, stuck in a room where people measured success in dollars, not in freedom.

Maybe that’s the point. Bitcoin Investment Week was never meant to be a pleb gathering.

That said, the week did have some bright spots. PubKey was a fantastic kickoff. That was real Bitcoin culture—plebs, Nostr, grassroots energy. People who actually use Bitcoin, not just talk about it.

But the absolute highlight? Jack Mallers, sneakers and all, cutting through the noise with his authenticity.

So, why did we even go?

Good question. Maybe it was curiosity. Maybe it was stepping out of our usual circles to see Bitcoin through a different lens. Maybe it was to remind ourselves why we chose this path in the first place.

Would I go again? Probably not.

Would I trade Prague, Riga, bitcoin++ or any of the grassroots Bitcoin conferences for this? Not a chance.

At the end of the day, Bitcoin doesn’t belong to Wall Street from my opinion. It belongs to the people who actually use it. And those are the people I want to be around.

@ 3bf0c63f:aefa459d

Rede Relâmpago

Ao se referir à Lightning Network do O que é Bitcoin?, nós, brasileiros e portugueses, devemos usar o termo "Relâmpago" ou "Rede Relâmpago". "Relâmpago" é uma palavra bonita e apropriada, e fácil de pronunciar por todos os nossos compatriotas. Chega de anglicismos desnecessários.

Exemplo de uma conversa hipotética no Brasil usando esta nomenclatura:

– Posso pagar com Relâmpago?

– Opa, claro! Vou gerar um boleto aqui pra você.

Repare que é bem mais natural e fácil do que a outra alternativa:

– Posso pagar com láitenim?

– Leite ninho?

@ 8947a945:9bfcf626

Law of diminishing returns : ทำมากได้น้อย ซวยหน่อยขาดทุน

** หมายเหตุ บทความนี้มีเนื้อหาต่อเนื่องจาก “(TH) Why I quit : สาเหตุที่ผมลาออกจากที่(ทำงาน) ที่ (เคย) เรียกว่า”บ้าน” ใครยังไม่ได้อ่าน แนะนำให้ไปอ่านก่อนนะครับ

ผมได้ยิน คุณท็อป จิรายุส (คุณท๊อป บิทคับ) พูดคำว่า "Law of diminishing returns" ไว้ตอนแชร์มุมมองด้านการทำธุรกิจ ตอนนั้นผมไม่เข้าใจ แต่ผมรู้สึกว่ามันเป็นเจ๋งดี

สำหรับผม สรุปกฏนี้สั้นๆ คือ “ทำมากได้น้อย ซวยหน่อยขาดทุน”

กฏข้อนี้ว่าด้วยเรื่องการทำธุรกิจ พูดถึงปัจจัย 3 อย่าง - Fixed input คือสิ่งที่ไม่สามารถผลิตเพิ่มได้อีกในธุรกิจตอนนั้น เช่น จำนวนห้องตรวจในโรงพยาบาล, พื้นที่ที่ดินทำการเกษตร, ห้องเก็บสินค้า, จำนวนโต๊ะทำงานในสำนักงาน, ช่องบริการลูกค้าในธุรกิจบริการต่างๆ เป็นต้น ผมขอเรียกสั้นๆว่า “พื้นที่” - Variable input คือสิ่งที่สามารถเติมเข้ามาในธุรกิจได้ ปรับแต่งได้ เช่น แรงงาน เครื่องจักร พลังงาน - Marginal product คือผลลัพธ์ของธุรกิจ กำไรเพิ่มขึ้นหลังจากเพิ่ม variable input เข้าสู่ระบบ

ระยะของ law of diminishing returns

• Increased return (ทำเงินได้เยอะขึ้น) เมื่อป้อนแรงงานหรือเครื่องจักรเข้าสู่ระบบ ธุรกิจสามารถทำเงินเพิ่มขึ้นเนื่องจาก fixed input เดิมที่ถูกใช้สอยไม่เต็มที่ (underutilized) ถูกเติมเต็ม กรณีของรพ. คือมีห้องตรวจที่ว่าง ไม่มีหมอนั่งตรวจคนไข้ ห้องตรวจนั้นก็จะไม่สร้างรายได้ แต่เมื่อห้องนั้นมีหมอมานั่ง จะเปลี่ยนเป็นพื้นที่ที่ก่อให้เกิดรายได้ เมื่อห้องตรวจทุกห้องมีหมอนั่งครบ ถือว่าเต็มศักยภาพ ประสิทธิภาพการทำงานที่ดีตามมา
• Diminishing return (ทำมากได้น้อย) จุดของความพอดี (optimum point) คือจุดที่สมดุลพอดีของธุรกิจนั้น ทำกำไรได้เหมาะสม ไม่มากไม่น้อยจนเกินไป แต่ถ้ามองไม่เห็นจุด optimum นี้แล้วยังเพิ่ม”แรงงาน”เข้าไปอีก มันจะทำให้ ”พื้นที่” วุ่นวายเละเทะ ประสิทธิภาพในการทำงานลดลง
• Negative returns (ซวยหน่อยขาดทุน) ถ้ายังไม่หยุดเพิ่ม “แรงงาน” อีก สามารถนำมาสู่การขาดทุน

สรุปเป็นกราฟหน้าตาตามนี้ครับ

ทำไมมันถึงเป็นอย่างนั้น

ผมใช้โมเดลธุรกิจรพ.นี้เป็นตัวอย่างเลยนะครับ

ช่วงแรกที่สร้างรพ. ห้องตรวจมีไม่มาก จำนวนหมอและคนไข้สมดุลกันพอดี งานไม่หนักเกินไป การดูแลคนไข้มีประสิทธิภาพ รพ.เป็นที่ไว้ใจของคนในพื้นที่ มีชื่อเสียง ถูกบอกต่อ ทำให้จำนวนคนไข้เข้ามารับบริการมากขึ้น ต้องขยายพื้นที่รพ. สร้างตึกเพิ่ม รับบุคคลากรทุกระดับเข้ามาทำงานมากขึ้น จนเต็มพื้นที่ที่ดินรพ.ไม่สามารถขยายเพิ่มไปได้มากกว่านี้แล้ว เกิดสมดุลพอดี ทุกพื้นที่ถูกใช้งานเต็มศักยภาพ ประสิทธิภาพงานดีมาก

ผลการดำเนินงาน

ไม่เคยขาดทุน ผ่านช่วงวิกฤตต้มยำกุ้ง และ COVID ได้สบายๆ ฐานะทางการเงินแข็งแรง จ่ายปันผลสม่ำเสมอ ถ้าผมเป็นเจ้าของรพ.ผมจะ 1. สร้างระบบ 2. สร้างทีมผู้บริหาร 3. เน้นย้ำความสำคัญทำตามระบบ 3. Plan - Do- Check - Act เมื่อเกิดปัญหา

เพื่อให้ตัวผมสามารถถอยตัวเองออกมาจากตัวธุรกิจ คอยติดตาม monitor ทุกไตรมาส อย่างใกล้ชิด ไม่ทำอะไรเพิ่มไปมากกว่านี้

แต่สุดท้ายมันก็เกิดเหตุการณ์ทายาทรุ่นที่ 2 “ไม่เอา” นั่นแหละครับ มันทำให้วัฒนธรรมองค์กรเปลี่ยน ก้าวเท้าเข้าไปสู่ยุคตกต่ำ

บริหารแบบล้าหลัง ทำอะไรไม่สุด คิดว่าทำแล้วแต่จริงๆคือไม่ได้ทำ แก้ปัญหาไม่ตรงจุดสร้างปัญหากว่าเดิม

---

ตัวอย่าง

1. นโยบายการประหยัดพลังงานเพื่อลด carbon footprint

ฟังดูเหมือนจะดี แต่รพ.สื่อสารให้

รณรงค์ให้ปิดไฟ ... ปิดแอร์เมื่อไม่ใช้งาน ...

ผมว่าประโยคนี้มันคุ้นๆ เหมือนเคยได้ยินมามากกว่า 10 ปีแล้ว ... หรือผมเข้าใจผิดหรือเปล่าไม่แน่ใจ

รณรงค์แค่นี้แหละครับ เรื่องลด carbon footprint ไม่ได้เป็นการคิดอะไรใหม่ๆที่เหมาะกับยุคสมัย หรือสร้างอะไรที่จับต้องได้ (objective)

แต่สิ่งที่ทำสวนทางโดยสิ้นเชิงคือใช้พลาสติกแบบใช้แล้วทิ้ง (single use plastic) เป็นภาชนะหลักในการบรรจุอาหารของแพทย์ และผู้เข้าร่วมประชุมงานใหญ่ๆ มีเสียงเสนอแนะจากบุคคลากรทุกระดับว่าให้ทำเป็นบุฟเฟ่ต์ จานชามช้อนส้อมแบบปกติก็ได้ เสนอกันมา 5 ปี ก็ยังคงไม่่มีการเปลี่ยนแปลง ได้รับแจ้งลงมาว่าใช้ภาชนะพลาสติกมันประหยัดกว่า เอาเป็นว่ากล่องข้าวพลาสติกมีการใช้อย่างน้อย 1200 กล่องต่อเดือน … คาดว่าสมการการปล่อยก๊าสคาร์บอน (carbon emission) ที่ทีมผู้บริหารคำนวณ อาจจะซับซ้อนเกินความเข้าใจของผมก็ได้นะครับ

2. การตลาดที่ล้มเหลวและพาแพทย์ซวย

ทำการตลาดไม่เข้าเป้า “เหมือนจะ” ทำ digital marketing แต่ทำแค่โพสกราฟฟิคโปรโมชั่นภาพนิ่งลงสื่อโซเชียลทุกช่องทาง แล้วบอกว่านั่นคือ digital marketing

... แต่เดี๋ยวก่อนๆๆๆ ...

ผมจะบอกว่าการโพสมันเป็นแค่ 1 ใน 10 ของ digital marketing แต่รพ.เข้าใจว่าตัวเองได้เข้าสู่ digital marketing แล้ว

... จริงๆมันไม่ใช่เลยเว้ย ...

ผลลัพธ์คือไม่สามารถเปิดน่านน้ำลูกค้าใหม่ได้เลย ได้แต่ฐานลูกค้าเดิมที่มี brand royalty (แต่แนวโน้มลดลง)

แถมที่แย่ที่สุดคือทำการตลาดแพคเกจออกมาโดยไม่ปรึกษาแพทย์ก่อนว่ามันขัดต่อมาตรฐานการรักษาหรือไม่ กลายเป็นทำแพคเกจดึงดูดคนไข้เข้ามาใช้บริการ แต่การรักษาในแพคเกจขัดต่อมาตรฐานการรักษาของแพทย์

คนไข้ไม่รู้หรอกครับ คนไข้จะเอาตามที่มีในแพคเกจ เขาจ่ายตังค์แล้ว แต่ความซวยมันไปตกอยู่กับแพทย์

3. วางกลยุทธไม่เข้าเป้า

ทุกๆต้นปีทางผู้บริหารจะประกาศกลยุทธประจำปี ว่าในปีนั้นๆรพ.จะมุ้งเน้นพัฒนาด้านไหน รพ.นี้มีปัญหาที่เป็นงูกินหางมานาน มันส่งผลต่อประสิทธิภาพการทำงานของหมอและพยาบาล มีการเสนอแก้ปัญหาเรื่องนี้วนซ้ำซากมา 5 ปี แต่ไม่ได้รับแก้ไขจริงจัง (ผมขอไม่เล่านะครับ)

แต่กลยุทธประจำปี 3 ปีที่ผ่านมา พุ่งใส่ตัวบุคคลากร เน้นพฤติกรรมบริการที่ดีเลิศ ทราบมาว่ามีการลงทุนกับโครงการนี้หลักแสนหรือหลักล้าน มีการจัด workshop เชิญวิทยากรและ trainer จากบริษัทภายนอก (outsource) เข้ามาอบรม เป็นโครงการที่เน้นให้บุคคลากรทุกคนเข้าอบรม 100%

ผมมองว่าปัญหาที่เป็นราก (root cause) มันยังไม่ถูกแก้เลย เปรียบเทียบเหมือนฐานรากของอาคารที่มันโคลงเคลงๆไม่มั่นคงยังไม่ได้รับการแก้ไข แต่พยายามตกแต่งห้องด้วยวัสดุคุณภาพดีและเทคโนโลยีที่ทันสมัย … แต่พร้อมจะล้มลงมาได้ทุกเมื่อ

4. มีเสน่ดึงดูด partner ใหม่ๆ แต่ไม่เอาเอง

ในช่วง COVID ระลอกแรก มีผู้นำทางด้านธุรกิจโรงแรมในจังหวัดมานำเสนอโมเดลธุรกิจ “hospitel เปลี่ยนโรงแรมให้เป็นโรงพยาบาล” ด้วยศักยภาพของรพ.ที่มีบุคคลากรเพียงพอ และตัวโรงแรมที่นำมาเสนอมีห้องพักประมาณ 300 ห้อง เป็นโมเดลที่รพ.และโรงแรม win-win ทั้งคู่ แต่ทางผู้บริหารมองว่าไม่คุ้ม ปฏิเสธข้อเสนอนี้ ทำให้เสียโอกาสให้กับคู่แข่งคว้าตลาด blue ocean นี้ไป

ผมได้แต่เกาหัวตอนรู้เรื่องนี้ เพราะ 1. ช่วง COVID คนไข้น้อย พนักงานโดนลดชั่วโมงการทำงาน ได้เงินเดือนขั้นต่ำ ไม่ได้ OT 2. ทาง partner เสนอขอบุคคลากรเหล่านี้แหละ ไปช่วยงาน เรื่องสถานที่ทางโรงแรมเขามีแม่บ้าน ฝ่ายทำความสะอาดอยู่แล้ว 3. ทาง partner เสนอ profit sharing กับทางรพ. ถึงผมจะไม่รู้ตัวเลข แต่เชื่อว่ามันยุติธรรม

ผมก็ไม่รู้ครับ ว่าอะไรคือคุ้มสำหรับผู้บริหาร

5. Top down absolute power

ไม่ฟังข้อเสนอจากตัวแทนหมอ คนที่มีอำนาจการตัดสินใจไม่เคยเอาตัวลงมาคุยกับหมอแบบจริงจังเลย

1-2 ปีจะลงมาพบหมอทั้งรพ.ซักหนึ่งครั้ง สร้างภาพเก่ง พูดขายฝันสวนหรูถึงภาพที่เขาต้องการ สั่งการลงมา พอเกิดปัญหาตัวเองไม่ลงมารับผิดชอบ แต่อาศัยหน่วยข่าวกรอง(ที่ไม่รู้ว่ากรองอะไรเข้าไปบ้าง) ออกคำสั่งแก้ผ้าเอาหน้ารอดลงมาทีหลัง

แถมสั่งให้เงียบและหุบปาก

ครั้งหนึ่งมีคำสั่งออกมาไม่ชัดเจน จนพยาบาลทำงานไม่ได้ ตัวแทนพยาบาลต้องโทรมาหาผมเพื่อให้ผมช่วย

ผมรวบรวมข้อมูลทั้งหมดและพบว่าคำสั่งมีปัญหาจริงๆ ผมจึง chat line ลงไปสอบถามผู้บริหารเพื่อขอความชัดเจน

… ผ่านไปไม่ถึง 5 นาที หนึ่งในผู้บริหาร(คนที่แทงข้างหลังผมที่หาว่าผมมาตรวจคนไข้ VIP เขาช้า 5 นาทีนั่นแหละ)โทรหาผมทันทีคุยกับผมสั้นๆ ใจความว่า “คำสั่งนั้นเอาแบบเดิม ไม่ต้องแก้ และให้ผมเงียบๆซะ”... (ก็ได้วะครับ)

จุดเปลี่ยนที่ทำให้รพ.เข้าสู่ law of diminishing returns

ห้องตรวจทุกห้องของรพ. ถูกใช้จนเต็มศักยภาพ … เอาจริงๆคือล้นศักยภาพเสียอีก (over-utilized) บางแผนกมีเก้าอี้ดนตรี - หมอคนแรกหมดเวลาออกตรวจ - หมอคนต่อไปเดินเข้าใช้ห้องตรวจต่อทันที - ถ้าไม่ทันก็ต้องคว้าห้องตรวจที่ว่างพร้อมใช้งานก่อน - หมอทำการไล่ที่กันเอง - หมอบางท่านต้องใช้ห้องทำงานของพยาบาลเป็นห้องตรวจชั่วคราว

ห้องพักผู้ป่วยก็เช่นกัน บางช่วงเตียงเต็มจนไม่สามารถ admit คนไข้ได้

แต่จำที่ผมบอกได้มั้ยครับว่า คนที่เป็น top down absolute power ไม่เคยเอาตัวลงมาพูดคุยกับแพทย์เพื่อรับฟังปัญหาที่แท้จริงเลย รับแต่ข่าวกรอง(ที่ไม่รู้ว่ากรองอะไรเข้าไปบ้าง) ช่วงนึงมีคนไข้ complaint ว่ารอนั่งรอหมอนาน หมอมาตรวจช้า ผู้บริหารเลยพยายามจะแก้ปัญหา โดยการ monitor waiting time (ระยะเวลารอหมอ) หยิบยกเรื่องนี้ขึ้นมาเป็นวาระเร่งด่วนต้องรีบแก้ไข

แต่เขายังงงๆกับ concept waiting time อยู่เลยว่าจะนับตั้งแต่ตอนไหนถึงตอนไหน - Waiting time สั้นแปลว่าดี เพราะคนไข้ได้เจอหมอเร็ว - Waiting time นานแปลว่าไม่ดี เพราะคนไข้นั่งรอหมอนาน

เขาตีความจากตัวเลขครับ แต่เคยเอาตัวลงมาดูจริงๆหรือเปล่าว่าทำไมตัวเลขมันถึงออกมาไม่ดี

คำตอบคือ“ไม่” ครับ

หมอบางสาขามีความจำเป็นต้องไปดูคนไข้ที่อาการหนักใช้เวลารักษานาน ... หรือ ... รับปรึกษาจากแพทย์ต่างสาขา ... หรือ ... เป็นสาขาเฉพาะทางของเฉพาะทางอีกที ต้องใช้เวลาตรวจละเอียดตรวจนาน

มันเป็นกระบวนการทำงานของหมอ ที่หมอด้วยกันเข้าใจกัน

ส่วนคนเก็บข้อมูลก็นำเสนอไปทั้งอย่างนั้นโดยที่ไม่ได้วิเคราะห์อะไรเลย มันเป็นการกรองข้อมูลที่ไม่รอบคอบก่อนนำเสนอผู้บริหาร

สุดท้ายผู้บริหาร “โทษหมอ” ว่าไม่มีการบริหารเวลาทำงานที่ดีเพียงพอ ทำให้คนไข้รอนาน เขาสรุปกันดื้อๆแบบนี้เลยครับ

พอหนักๆเข้า “รอหมอนาน ต้องเพิ่มหมอ” season การรับสมัครหมอหลายตำแหน่งได้เริ่มขึ้น

แต่เดี๋ยวนะ ห้องตรวจมันแน่นจนแทบไม่มีที่ให้หมอนั่งทำงานแล้ว แต่เขาก็ไม่สนครับ รับหมอหน้าใหม่ๆมาเพิ่มเรื่อยๆ

ด้วย mindset ว่า "ต้องเพิ่มหมอ หมอจะได้เยอะขึ้น คนไข้จะได้ไม่ต้องรอนาน" และเชื่อว่าจะทำรายได้ให้รพ.มากขึ้น หมอหน้าใหม่บางท่านเข้ามาทำงานวันแรกถึงขั้นอยู่ในสภาวะ dead air คือไม่มีที่ให้นั่งทำงาน

“ทำมากได้น้อย” เริ่มต้น

คนไข้รพ.นี้ ส่วนใหญ่เป็นโรคซับซ้อน ต้องการทักษะและเวลาหมอเฉพาะทางแต่ละสาขาอยู่ดี ไม่ได้ทำให้ waiting time ดีขึ้น คนไข้ยัง “นั่งรอหมอนานเหมือนเดิม”

รายได้เริ่มลดลง ยอดคนไข้เริ่มลดลง รพ.พยายามแก้เกมโดยการเพิ่มราคาค่าบริการ (เพิ่มขนาด ticket size) ทำให้มีเสียงรีวิวตามโซเชียลว่า "แพง"

ผลที่เกิดขึ้นคือคนไข้หลายคนอาศัยรพ.นี้ในการตรวจวินิจฉัยโรคแล้วเอาผลไปรักษาต่อรพ.รัฐบาลตามสิทธิ์เพราะสู้ราคาค่ารักษาไม่ไหว บางคนมีประกันสุขภาพหลายฉบับแต่ก็ต้องจ่ายส่วนต่างมากอยู่ดี

วิธีการข้างต้นนี้ ไม่ผิดกติกาครับ ผล X-ray , CT, MRI, ultrasound จากรพ.เอกชน ไวกว่ารพ.รัฐบาลอยู่แล้ว แต่ก็มีคนไข้บางส่วนยินดีจ่ายแพง เพราะเชื่อมั่นหมอที่รพ.นี้ไม่อยากย้ายรพ.ก็มีครับ เพราะหมอไม่ได้ทำอะไรผิด หมอเก่งๆมีเยอะ

ถึงแม้ว่ารพ.จะรักษา momentum มีจำนวนคนไข้ประมาณ 1100 - 1200 รายต่อวัน แต่ก็เป็นโรคง่ายๆ(simple disease) เช่นไข้หวัด อาหารเป็นพิษ เป็นต้น โรคเหล่านี้ ticket size ไม่ได้ใหญ่มาก ประคองไว้ไม่ให้ขาดทุนเท่านั้นครับ

แต่ความแพงแบบไม่สมเหตุสมผล ทำให้คนไข้หลายรายถอดใจย้ายรพ.ตั้งแต่ทราบค่าใช้จ่ายวินาทีแรก

คนไข้น้อยลง --> รายได้ลดลง --> เพิ่ม ticket size ต่อหัวให้แพงขึ้น --> คนไข้หนีเพราะแพงเกิน

ผมไม่รู้ว่าผู้บริหารเขาเห็นไหม แต่คาดว่าคงจะไม่เห็น

ส่วนโรคหรือการผ่าตัดที่สมศักดิ์ศรีกับศักยภาพของรพ. "น้อยมากจนแทบไม่มี" ไม่ใช่สาเหตุอื่นเลยครับ โดนรพ.คู่แข่งในรัศมี 20 กิโลเมตรเอาไปหมด เพราะราคาถูกกว่า หมอก็เก่งไม่แพ้กัน หมอบางคนเคยอยู่ที่รพ.แห่งนี้ เสนอโปรเจคการรักษาโรคบางโรคที่สามารถสร้างรายได้เป็นกอบเป็นกำ แต่ทางรพ.ไม่เอาเอง สุดท้ายหมอเหล่านั้นย้ายไปอยู่กับรพ.คู่แข่งและผลักดันโปรเจคเหล่านั้นสำเร็จจนมีชื่อเสียง

"รพ.ขายสินค้า premium ไม่ได้เลย ขายได้แต่สินค้าเกรดท้องตลาด"

กลยุทธที่รพ.ทำต่อมาคือเพิ่มจำนวนชั่วโมงการทำงานของหมอให้เพิ่มขึ้นโดยให้หมอมาทำงานเร็วขึ้น 2 ชม. แต่ไม่จ่าย OT ให้ ด้วยตรรกะว่าถ้าหมอทำงานนานขึ้น จะมีจำนวนคนไข้มากขึ้น ทางรพ.ไม่ได้ขอร้อง แต่บีบคอให้หมอร่วมมือ หากไม่ร่วมมือไล่ออกทันที

ไปๆมาๆ มีการไล่ออกกระทันหันเกิดขึ้น มีการส่งหนังสือส่วนตัวหาหมอทุกคน ใครมีรายชื่อที่จะปลดออกก็ต้องออกจากงานทันที

ผมมองว่าฐานะทางการเงินมีปัญหารุนแรงครับ เงินเดือนพนักงานถือเป็น fixed cost ที่ธุรกิจต้องแบกรับ ถ้าเจ๋งจริงต้องควบคุมรายจ่ายให้ธุรกิจสามารถไปต่อได้โดยไม่ปลดคน ในส่วนของธุรกิจรพ. หมอคือบุคคลากรที่สำคัญที่สุดและเป็นด่านสุดท้ายที่จะไล่ออกเพื่อรักษาชีวิตของธุรกิจ ตอนนี้รพ.ได้เข้าสู่ระยะสุดท้ายของ law of diminishing returns คือ “ซวยหน่อยขาดทุน” เป็นที่เรียบร้อยครับ

จุดจบของรพ.แบบนี้ ที่ศักยภาพดี แต่บริหารห่วยแตก มันจะจบด้วยการถูก take over ผ่านมาไม่นานกราฟหุ้นออกอาการ exit liquidity แล้วครับ

ข้อคิดที่อยากแบ่งปันกับทุกคนที่อ่านมาจนจบ

1. ช่วงธุรกิจเปลี่ยนผ่านสู่ทายาท คือจุดวัดใจหัวเลี้ยวหัวต่อว่าจะรอดหรือไม่รอด
2. Law of diminishing returns ไม่ได้ใช้เฉพาะกับธุรกิจ แต่สามารถประยุกต์ใช้กับการดำเนินชีวิตได้หลายมิติ หากใครเข้าใจ จะขยับเข้าสู่ Pareto’s rule … สั้นๆคือ ทำน้อยแต่ได้(โคตร)มาก
3. เจ้าของธุรกิจ ต้องหูไว มองหาเนื้อร้ายที่คอยกัดกินธุรกิจให้เจอ แล้วกำจัดมันซะ ก่อนที่ธุรกิจจะล้มทั้งยืน ทับตัวเองตาย

@ 3bf0c63f:aefa459d

The Lightning Network solves the problem of the decentralized commit

Before reading this, see Ripple and the problem of the decentralized commit.

The Bitcoin Lightning Network can be thought as a system similar to Ripple: there are conditional IOUs (HTLCs) that are sent in "prepare"-like messages across a route, and a secret p that must travel from the final receiver backwards through the route until it reaches the initial sender and possession of that secret serves to prove the payment as well as to make the IOU hold true.

The difference is that if one of the parties don't send the "acknowledge" in time, the other has a trusted third-party with its own clock (that is the clock that is valid for everybody involved) to complain immediately at the timeout: the Bitcoin blockchain. If C has p and B isn't acknowleding it, C tells the Bitcoin blockchain and it will force the transfer of the amount from B to C.

Differences (or 1 upside and 3 downside)

1. The Lightning Network differs from a "pure" Ripple network in that when we send a "prepare" message on the Lightning Network, unlike on a pure Ripple network we're not just promising we will owe something -- instead we are putting the money on the table already for the other to get if we are not responsive.

2. The feature above removes the trust element from the equation. We can now have relationships with people we don't trust, as the Bitcoin blockchain will serve as an automated escrow for our conditional payments and no one will be harmed. Therefore it is much easier to build networks and route payments if you don't always require trust relationships.

3. However it introduces the cost of the capital. A ton of capital must be made available in channels and locked in HTLCs so payments can be routed. This leads to potential issues like the ones described in https://twitter.com/joostjgr/status/1308414364911841281.

4. Another issue that comes with the necessity of using the Bitcoin blockchain as an arbiter is that it may cost a lot in fees -- much more than the value of the payment that is being disputed -- to enforce it on the blockchain.[^closing-channels-for-nothing]

Solutions

Because the downsides listed above are so real and problematic -- and much more so when attacks from malicious peers are taken into account --, some have argued that the Lightning Network must rely on at least some trust between peers, which partly negate the benefit.

The introduction of purely trust-backend channels is the next step in the reasoning: if we are trusting already, why not make channels that don't touch the blockchain and don't require peers to commit large amounts of capital?

The reason is, again, the ambiguity that comes from the problem of the decentralized commit. Therefore hosted channels can be good when trust is required only from one side, like in the final hops of payments, but they cannot work in the middle of routes without eroding trust relationships between peers (however they can be useful if employed as channels between two nodes ran by the same person).

The next solution is a revamped pure Ripple network, one that solves the problem of the decentralized commit in a different way.

[^closing-channels-for-nothing]: That is even true when, for reasons of the payment being so small that it doesn't even deserve an actual HTLC that can be enforced on the chain (as per the protocol), even then the channel between the two nodes will be closed, only to make it very clear that there was a disagreement. Leaving it online would be harmful as one of the peers could repeat the attack again and again. This is a proof that ambiguity, in case of the pure Ripple network, is a very important issue.

@ 502ab02a:a2860397

หลังจากที่เราได้ทราบถึงโครงการ School Plates กันไปแล้ว วันนี้เรามาทำความรู้จักกับ ProVeg ผู้ที่อยู่เบื้องหลังโปรเจค School Plates กันครับ

ProVeg International เส้นทางสู่การเปลี่ยนแปลงระบบอาหารโลก

ProVeg International เป็นองค์กรไม่แสวงหาผลกำไรระดับโลกที่ก่อตั้งขึ้นในปี 2017 โดยมีเป้าหมายหลักในการลดการบริโภคผลิตภัณฑ์จากสัตว์ลง 50% ภายในปี 2040 และแทนที่ด้วยอาหารจากพืชและอาหารที่เพาะเลี้ยงในห้องปฏิบัติการ ​

องค์กรนี้มีจุดเริ่มต้นจากการรวมตัวของกลุ่มองค์กรด้านอาหารจากพืชในหลายประเทศ เช่น เยอรมนี (ProVeg Deutschland), เนเธอร์แลนด์ (ProVeg Nederland ซึ่งเดิมคือ Viva Las Vega's), โปแลนด์, สหราชอาณาจักร และสเปน โดยมี Sebastian Joy เป็นผู้ร่วมก่อตั้งและดำรงตำแหน่งประธานคนแรกขององค์กร ​

ProVeg International มุ่งเน้นการเปลี่ยนแปลงระบบอาหารโลกผ่านการให้ข้อมูล การสนับสนุน และการรณรงค์ต่าง ๆ เพื่อส่งเสริมการบริโภคอาหารจากพืช องค์กรทำงานร่วมกับหน่วยงานรัฐบาล บริษัทเอกชน นักลงทุน สื่อมวลชน และสาธารณชน เพื่อผลักดันให้เกิดการเปลี่ยนแปลงในระดับระบบ

โครงการที่เริ่มไปแล้ว ProVeg Incubator หนึ่งในโครงการที่สำคัญของ ProVeg คือ "ProVeg Incubator" ซึ่งเป็นโปรแกรมสนับสนุนสตาร์ทอัพด้านอาหารจากพืชและอาหารที่เพาะเลี้ยงในห้องปฏิบัติการ โดยให้การสนับสนุนทั้งด้านเงินทุน การให้คำปรึกษา และเครือข่ายความร่วมมือ เพื่อเร่งการพัฒนาผลิตภัณฑ์และการเข้าสู่ตลาด ​

ตั้งแต่เปิดตัวในปี 2018 ProVeg Incubator ได้สนับสนุนสตาร์ทอัพกว่า 40 รายจาก 20 ประเทศ ช่วยให้พวกเขาระดมทุนได้มากกว่า 8 ล้านยูโร และเปิดตัวผลิตภัณฑ์กว่า 40 รายการ

สำหรับความพยายามในการล็อบบี้ นั้น ProVeg International มีบทบาทสำคัญในการล็อบบี้เพื่อส่งเสริมอาหารจากพืชในระดับนโยบาย โดยเฉพาะในสหภาพยุโรป ตัวอย่างผลงานที่โด่งดังมากคือ

"การต่อต้านการห้ามใช้ชื่อผลิตภัณฑ์จากพืช" ในเดือนพฤษภาคม 2019 คณะกรรมาธิการการเกษตรและการพัฒนาชนบท (Committee on Agriculture and Rural Development) ของรัฐสภายุโรปได้เสนอการแก้ไขในหมวด - Amendment 165 ซึ่งจะห้ามใช้ชื่อที่สื่อถึงเนื้อสัตว์ กับผลิตภัณฑ์ทางเลือกจากพืช (เช่น “vegetarian sausage”, “soy schnitzel” ฯลฯ) และ - Amendment 171 ซึ่งจะขยายไปถึงผลิตภัณฑ์ทดแทนผลิตภัณฑ์นม (เช่น “yoghurt-style”, “vegan cheese”, “almond milk”) โดยทั้งหมดนี้ใช้เหตุผลว่าอาจทำให้ผู้บริโภคสับสน​

ProVeg International ร่วมกับองค์กรอื่น ๆ เช่น IKEA และ Compassion in World Farming และบริษัทผู้ผลิตนมจากพืชอย่าง "Oatly" ได้รณรงค์ต่อต้านข้อเสนอเหล่านี้ รวมถึงการยื่นจดหมายถึงสมาชิกรัฐสภายุโรปและการจัดทำคำร้องออนไลน์ ซึ่งได้รับลายเซ็นมากกว่า 150,000 รายชื่อภายในเวลาไม่กี่วัน

ผลการโหวตวันที่ 23 ตุลาคม 2020 รัฐสภายุโรปลงมติ ปฏิเสธ Amendment 165 และไม่ยอมรับข้อเสนอห้ามใช้คำว่า “burger” “sausages” ในผลิตภัณฑ์จากพืช ส่วน Amendment 171 ถูกเลื่อนออกไป และสุดท้ายเมื่อเดือนพฤษภาคม 2021 ก็ถูกถอนออกจากการพิจารณา (withdrawn) อย่างเป็นทางการ ซึ่งถือเป็นชัยชนะของขบวนการ “stop plant-based censorship”

พูดง่ายๆคือ ProVeg International ต่อต้านการห้ามใช้ชื่อผลิตภัณฑ์จากพืชทั้งสองฉบับ (165 และ 171) ประสบความสำเร็จทั้งหมด !!!!!!

"การเรียกร้องแผนปฏิบัติการอาหารจากพืชของสหภาพยุโรป" ในปี 2023 ProVeg International ร่วมกับองค์กรกว่า 130 แห่ง เรียกร้องให้สหภาพยุโรปจัดทำแผนปฏิบัติการอาหารจากพืชภายในปี 2026 เพื่อส่งเสริมการเปลี่ยนแปลงระบบอาหารสู่ความยั่งยืน

นอกจากนี้ ProVeg ยังได้รับการยอมรับในระดับนานาชาติ โดยได้รับสถานะผู้สังเกตการณ์ถาวรจากกรอบอนุสัญญาสหประชาชาติว่าด้วยการเปลี่ยนแปลงสภาพภูมิอากาศ (UNFCCC) รวมถึง ProVeg ได้รับรางวัล United Nations' Momentum for Change Award และทำงานอย่างใกล้ชิดกับหน่วยงานอาหารและสิ่งแวดล้อมที่สำคัญของ UN และเป็นสมาชิกของศูนย์และเครือข่ายเทคโนโลยีด้านสภาพภูมิอากาศ (CTCN)

ด้วยวิสัยทัศน์ที่ชัดเจนและการดำเนินงานที่ครอบคลุม ProVeg International ได้กลายเป็นหนึ่งในองค์กรชั้นนำที่ขับเคลื่อนการเปลี่ยนแปลงระบบอาหารโลก

ในส่วนของสตาร์ทอัพภายใต้การสนับสนุนของ ProVeg Incubator ได้สนับสนุนสตาร์ทอัพที่มีนวัตกรรมและศักยภาพสูงหลายราย เช่น​ Formo: บริษัทจากเยอรมนีที่ผลิตชีสจากการหมักจุลินทรีย์ (precision fermentation) โดยไม่ใช้สัตว์ ​ Remilk: บริษัทจากอิสราเอลที่ผลิตนมจากการหมักจุลินทรีย์ โดยไม่ใช้วัว ​ Cultimate Foods: บริษัทที่พัฒนาไขมันจากเซลล์สัตว์เพื่อใช้ในผลิตภัณฑ์จากพืช ​ Infinite Roots: บริษัทที่ใช้เทคโนโลยีการเพาะเลี้ยงไมซีเลียม (mycelium) เพื่อผลิตโปรตีนทางเลือก ​ Kern Tec: บริษัทที่ใช้เมล็ดผลไม้ที่เหลือจากอุตสาหกรรมอาหารเพื่อผลิตน้ำมันและโปรตีน

และยังมีอีกร่วมๆ กว่า 40 รายจาก 20 ประเทศ ที่เป็นกองกำลังสำคัญในการพัฒนาอาหารอนาคตให้กับ ProVeg เพื่อขยายปีกในการครอบครองตลาดนี้เพื่อความยั่งยืน(ของใคร?)

คำถามที่น่าสนใจ ใครคือ Sebastian Joy ทำไมเขาสร้างองค์กรมาได้ขนาดนี้ Sebastian Joy เป็นคนเยอรมันครับ เขาไม่ใช่แค่คนที่สนใจอาหารจากพืชเฉย ๆ แต่เขาเป็นนักคิด นักเคลื่อนไหว และนักเชื่อมโยงระดับอินเตอร์ฯ ที่เปลี่ยนจากการรณรงค์เฉพาะกลุ่ม ไปสู่การสร้าง "ระบบนิเวศ" ของการเปลี่ยนแปลงพฤติกรรมการกินระดับโลกได้อย่างจริงจัง

ในเว็บไซต์ส่วนตัวของ Sebastian Joy ได้ขึ้นประโยคแรกว่าเขาเป็น Serial Social Entrepreneur working to transform the global food system

นั่นหมายถึงว่า ในโลกที่อาหารกลายเป็นเครื่องมือทางอำนาจ และแนวคิด "กินดีเพื่อโลก" ถูกผลักดันอย่างแข็งขันผ่านโครงการระดับโลก หนึ่งในผู้เล่นสำคัญที่อยู่เบื้องหลังกระแสนี้คือชายชื่อ Sebastian Joy ผู้ซึ่งไม่ได้เพียงเป็นนักเคลื่อนไหว แต่เป็น Serial Social Entrepreneur หรือ นักสร้างสรรค์องค์กรเพื่อสังคมต่อเนื่อง ที่มีวิสัยทัศน์ใหญ่ เปลี่ยนระบบอาหารของโลกทั้งใบ

ตลอดกว่า 20 ปีที่ผ่านมา Sebastian ไม่ได้เพียงแค่เปิดองค์กรหรือรณรงค์ทั่วไป แต่เขาเป็นผู้ผลักดันการถือกำเนิดขององค์กรไม่แสวงกำไร โครงการเร่งรัดธุรกิจเพื่อสังคม แพลตฟอร์มความร่วมมือ และเวทีระดับนานาชาติหลายสิบแห่งที่เกี่ยวกับอาหารจากพืช เขาคือผู้ก่อตั้งและประธานของ ProVeg International องค์กรที่อ้างว่าเป็น "องค์กรชั้นนำของโลกด้านความตระหนักเรื่องอาหาร" โดยมีเป้าหมายชัดเจนในการลดการบริโภคผลิตภัณฑ์จากสัตว์ลงอย่างเป็นระบบ

แต่บทบาทของเขาไม่ได้หยุดแค่การปลุกกระแสสุขภาพ เขาเป็นผู้อยู่เบื้องหลังงานแสดงสินค้า VeggieWorld ซึ่งกลายเป็นซีรีส์มหกรรมอาหารวีแกนที่ใหญ่ที่สุดในโลก และยังร่วมก่อตั้ง Animal and Vegan Advocacy Summit เวทีระดับนานาชาติสำหรับนักเคลื่อนไหวสายวีแกน

Sebastian ยังเป็นผู้ร่วมก่อตั้ง incubator แห่งแรกของโลก สำหรับสตาร์ทอัพที่ทำอาหารจากพืชและเนื้อเพาะเลี้ยง และเป็นผู้ผลักดันโปรแกรม Kickstarting for Good ที่เน้นเร่งรัดองค์กรไม่แสวงกำไรให้เดินเกมได้เร็วขึ้นด้วยโมเดลธุรกิจที่ยั่งยืน

นอกจากนี้ เขายังเป็นพาร์ตเนอร์ของ V-Label International (ฉลากมังสวิรัติที่มีอิทธิพลที่สุดในยุโรป), เป็นเมนเทอร์ในโครงการ Charity Entrepreneurship, และอดีตอาจารย์ด้าน Social Entrepreneurship ที่ Berlin School of Economics and Law

ผลงานของเขาและองค์กรได้รับรางวัลระดับนานาชาติหลายรายการ รวมถึงรางวัล Momentum for Change จากสหประชาชาติ ซึ่งถือเป็นเครื่องยืนยันว่า "แผนปฏิบัติการเปลี่ยนโลกผ่านจานอาหาร" ของเขาไม่ได้เป็นเพียงอุดมคติ แต่เป็นแผนที่กำลังถูกปักหมุดทั่วโลก

ย้อนกลับไปก่อนปี 2017 Sebastian เป็นผู้อำนวยการของ VEBU ซึ่งเป็นองค์กรอาหารจากพืชที่ใหญ่ที่สุดในเยอรมนี (VEBU ย่อมาจาก Vegetarierbund Deutschland) และเขาเองก็อยู่ในวงการนี้มาตั้งแต่ยุคที่การกิน plant-based ยังถูกมองว่าเป็นเรื่อง fringe หรือนอกกระแสเลยด้วยซ้ำ

เหตุผลที่เขาเริ่ม ProVeg International แล้วมัน “ไปไกล” ได้ ผมขมวดให้เป็นข้อๆเพื่อความง่ายต่อการเข้าใจประมาณนี้ครับ

1. Sebastian ไม่ใช่แค่นักกิจกรรม เขาคือนักกลยุทธ์ เขาไม่พอใจแค่การแจกโบรชัวร์หรือชวนคนงดเนื้อวันจันทร์ (จำตัวนี้ไว้ดีๆนะครับ จะมาเล่าภายหลัง) แต่เขามองระดับ “ระบบ” มองว่าโครงสร้างใหญ่ของ นโยบาย สื่อ เศรษฐกิจ การลงทุน มหาวิทยาลัย และซัพพลายเชนอาหาร ล้วนต้องเปลี่ยนไปพร้อมกัน เขาเลยสร้าง ProVeg ขึ้นมาเป็น “แพลตฟอร์มเปลี่ยนแปลงระบบ” ไม่ใช่แค่องค์กร NGO ธรรมดา

2. เขาสร้างพันธมิตรเก่ง Sebastian มีวิธีคุยกับนักลงทุนได้ เข้าใจ startup ได้ คุยกับผู้กำหนดนโยบาย EU ได้ และคุยกับผู้บริโภคได้ด้วย เรียกว่าพูดได้หลายภาษา (ทั้งภาษาคนและภาษายุทธศาสตร์) ทำให้ ProVeg ขยับตัวแบบ agile มาก และข้ามพรมแดนได้ไว ลงลึกถึงจิตใจเหล่า startup ได้แบบพวกเดียวกัน เป็นสตีฟ จ็อบส์ ที่เฟรนด์ลี่ เลยอ่ะ

3. มองอาหารจากพืชเป็น “โอกาส” ไม่ใช่ “การเสียสละ” แนวคิดที่เขาผลักดันคือ “ทำยังไงให้การกิน plant-based เป็นเรื่องสนุก มีรสชาติ มีนวัตกรรม และทำให้คนทั่วไปเลือกโดยไม่รู้สึกว่ากำลังงดของอร่อย ทำให้คนเลือกโดยที่ไม่รู้ตัวว่าถูกกำหนดเส้นทางให้เลือก” เขาจึงให้ความสำคัญกับ startup สายอาหารและเทคโนโลยีอาหารมาก มากจนกลายมาเป็นโครงการ ProVeg Incubator กองกำลังอาหารอนาคต นั่นแหละครับ

คำพูดหนึ่งของ Sebastian ที่ถูกนำมากล่าวถึงบ่อยๆคือ It’s easy to judge the mistakes of parents or grandparents, but what are going to be the mistakes that our future grandchildren will judge us by?

เขาไม่ได้ต้องการแค่ทำให้มี “เบอร์เกอร์ที่ไม่มีเนื้อ” แต่เขาต้องการเปลี่ยนทั้งระบบอาหารให้สะท้อนค่านิยมใหม่ เหมือนที่มีการพยายามจะสะท้อนมูฟนี้ไว้ว่า

“They are not just replacing products. They are building a food system that reflects their values.”

และวิศัยทัศน์ซึ่งเขาได้อธิบายถึงแนวทางของ ProVeg ว่าไม่ได้มุ่งเน้นเฉพาะเรื่องสวัสดิภาพสัตว์เท่านั้น แต่เป็นการเปลี่ยนแปลงระบบอาหารโดยรวม เพื่อประโยชน์ต่อรสชาติ สุขภาพ ความยุติธรรม สัตว์ และสิ่งแวดล้อม We don’t frame ourselves as an animal charity but as a food awareness organisation. And we follow what we call the ‘five pros’: pro-taste, pro-health, pro-justice, pro-animals and pro-environment

เป็น 5 Pro ที่ต้องจับตามองเสียแล้วครับ

อย่างที่บอกครับว่า มันเกิดขึ้นไปแล้ว และ 2 คำพูดที่เราเคยพูดไว้เราจะยังคงยืนยันได้ตามนั้นไหม "คงโชคดีที่ตายก่อนวันนั้น" และ "ก็แค่เลือกไม่กิน" น่าคิดแล้วครับ

#pirateketo #กูต้องรู้มั๊ย #ม้วนหางสิลูก #siamstr

@ 3bf0c63f:aefa459d

Liquidificador

A fragilidade da comunicação humana fica clara quando alguém liga o liquidificador.

@ 3bf0c63f:aefa459d

Músicas novas e conhecidas

Quando for ouvir música de fundo, escolha músicas bem conhecidas. Para ouvir músicas novas, reserve um tempo e ouça-as com total atenção.

Uma coisa similar é dirigir por caminhos conhecidos versus dirigir em lugares novos. a primeira opção te permite fazer coisas enquanto dirige "de fundo", a segunda requer atenção total.

Com músicas, tenho errado constantemente em achar que posso conhecer músicas novas ao mesmo tempo em que me dedico a outras tarefas.

See also:

• Músicas que você já conhece

@ d34e832d:383f78d0

First Contact – A Film History Breakdown

🎥 Movie: Contact
📅 Year Released: 1997
🎞️ Director: Robert Zemeckis
🕰️ Scene Timestamp: ~00:35:00

---

In this pivotal moment, Dr. Ellie Arroway (Jodie Foster), working at the VLA (Very Large Array) in New Mexico, detects a powerful and unusual signal emanating from the star system Vega, over 25 light-years away. It starts with rhythmic pulses—prime numbers—and escalates into layers of encoded information. The calm night shatters into focused chaos as the team realizes they might be witnessing the first confirmed evidence of extraterrestrial intelligence.

---

🎥 Camera Work:
Zemeckis uses slow zooms, wide shots of the VLA dishes moving in synchrony, and mid-shots on Ellie as she listens with growing awe and panic. The kinetic handheld camera inside the lab mirrors the rising tension.

💡 Lighting:
Low-key, naturalistic nighttime lighting dominates the outdoor shots, enhancing the eerie isolation of the array. Indoors, practical lab lighting creates a realistic, clinical setting.

✂️ Editing:
The pacing builds through quick intercuts between the signal readouts, Ellie’s expressions, and the reactions of her team. This accelerates tension while maintaining clarity.

🔊 Sound:
The rhythmic signal becomes the scene’s pulse. We begin with ambient night silence, then transition to the raw audio of the alien transmission. It’s diegetic (heard by the characters), and as it builds, a subtle score underscores the awe and urgency. Every beep feels weighty.

---

Released in 1997, Contact emerged during a period of growing public interest in both SETI (Search for Extraterrestrial Intelligence) and skepticism about science in the post-Cold War world. It was also the era of X-Files and the Mars Pathfinder mission, where space and the unknown dominated media.

The scene reflects 1990s optimism about technology and the belief that answers to humanity’s biggest questions might lie beyond Earth—balanced against the bureaucratic red tape and political pressures that real scientists face.

• Classic procedural sci-fi like 2001: A Space Odyssey and Close Encounters of the Third Kind.
• Real-world SETI protocols and the actual scientists Carl Sagan consulted with.
• The radio broadcast scene reflects Sagan’s own passion for communication and cosmic connectedness.

This scene set a new benchmark for depicting science authentically in fiction. Many real-world SETI scientists cite Contact as an accurate portrayal of their field. It also influenced later films like Arrival and Interstellar, which similarly blend emotion with science.

---

The signal is more than data—it’s a modern miracle. It represents Ellie’s faith in science, the power of patience, and humanity's yearning to not be alone.

The use of prime numbers symbolizes universal language—mathematics as a bridge between species. The scene’s pacing reflects the clash between logic and emotion, science and wonder.

The signal itself acts as a metaphor for belief: you can't "see" the sender, but you believe they’re out there. It’s the crux of the entire movie’s science vs. faith dichotomy.

---

This scene hits hard because it captures pure awe—the mix of fear, wonder, and purpose when faced with the unknown. Watching Ellie realize she's not alone mirrors how we all feel when our faith (in science, in hope, in truth) is rewarded.

For filmmakers and students, this scene is a masterclass in procedural suspense, realistic portrayal of science, and using audiovisual cues to build tension without needing action or violence.

It reminds us that the greatest cinematic moments don’t always come from spectacle, but from stillness, sound, and a scientist whispering: “We got something.”

@ 1c19eb1a:e22fb0bc

It's been barely two years since I joined Nostr on my main npub, nostr:npub1kun5628raxpm7usdkj62z2337hr77f3ryrg9cf0vjpyf4jvk9r9smv3lhe, and in just that relatively short time, the amount of development on top of this protocol has been staggering. When nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m first opened the floodgates of adoption by tweeting about Nostr, it felt like most of the available clients were barely serviceable and held together with a prayer and copious amounts of duct tape. Of course, it can sometimes still feel that way, but there are definitely some Nostr apps looking and feeling more polished and providing true innovation when compared with legacy social platforms. Indeed, there are a growing number of Nostr-based applications and tools that have very little to do with social media at all.

One thing we have not had available to the growing Nostr community, and those considering joining it, is a source for application reviews that is thorough, approachable, knowledgeable, and balanced. This is what I hope to begin to provide through this new npub dedicated to reviewing as many of the Nostr clients, apps, and tools as I possibly can, so you the reader can determine which ones will fit your needs, and perhaps help you find new ones you had never heard about.

One of the best parts about Nostr is the portability of your identity and social graph, allowing users to log into any Nostr-based application with their same "account" without some centralized tech giant like Google or Apple owning who you are and all of your data. Leverage this super-power of Nostr with me as we explore the best applications and tools the intrepid developers building on this platform have cooked up.

What will you review?

My choice of applications to review will be based on a few factors.

First, I will only be reviewing applications that have a production release, or are otherwise considered production ready by the developer. nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s, you won't have to worry that I will be putting NoteDeck under the microscope while it is still very much in alpha. All of us who love to try the new clients as soon as they are available understand well enough that there will be plenty of bugs, UI quirks, and rough edges to look past.

Second, I will generally be reviewing applications that are meant to be user-facing for the average person. That is, apps that your normie friends might soon be using, and then asking you why they can't edit anything they post. I will not be doing reviews of various relay implementations, for instance, unless they are designed to be approachable to the average user to install and manage. nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h, your project might just be a notable exception.

Third, my reviews will be limited by the operating systems I have available to me at the time. Sorry folks over on iOS, Mac, and Windows. I will only be able to review apps I can run on Android, Linux, or my web browser for the time being.

How will the apps be rated?

I want to be thorough in my reviews, and yet avoid overloading my readers with information they don't care about. In order to attempt to achieve this, I will break my reviews into several sections, so readers can skip to the sections relevant to their interests.

First, I will provide a basic overview of the type of application I am reviewing, what it is trying to achieve, and why a user might want to try it out.

Next, I will give my overall impression of the application. The good, the bad, and the ugly, as it were, so that those who just want a brief rundown can get the TLDR right out the gate and be on their way.

Then we will begin diving into the nitty-gritty with an in depth look at the main features of the application. What it does well. What features seem lacking. What expected features are absent. What features make it unique and set it apart from other applications with a similar purpose.

For the sake of all the baby Nostriches out there, the next section will be an assessment of how approachable the application would likely be to a normie who is coming to Nostr with no idea what a public and private key are, what relays are, or why they might want to start interacting here instead of on a legacy equivalent. What would someone used to Twitter think of #Snort? What would someone used to Spotify think of #Fountain or #Wavlake?

The next section will be a review of the application's UI. The design and polish. How easy it is to find the things you want in the areas you would expect them. In short, how well the application achieves the goal of making the user feel at home and want to continue using the app just through quality UI design.

If you know me and my contstant harping on developers to include various forms of external signing, it should be no surprise to you that the next section will cover login options. What does the sign-in and sign-up flow look like, and does the user have to expose their private key to the application in order to use it?

A review of virtually any Nostr application would be incomplete without a section dedicated to zap integration. How prominent is zapping in the app? How easy is it to zap or start receiving zaps? Are zaps displayed in a way that encourages users to compete to be top zapper? Is Nostr Wallet Connect supported for using external wallets for one-tap-zapping?

Most Nostr applications, even "other stuff" clients, are designed to present some form of content to the user. The next section will cover how easy it is for the user to find the type of content they may be interested in, or to discover content they didn't know they might be interested in. For social clients, how easy is it to discover other users that they might want to follow?

The backbone of the protocol is the interplay between clients and relays, and the next section of the review will cover how the app manages relays. Are they hidden from the user? Are there sensible defaults? Can users who want to do so select the relays they prefer? Does the app respect relays the user has selected in other apps, or are the app's relays independent of those selected in other apps. Worse, does the app overwrite your selected relays with its defaults?

Finally, I will scour the #AskNostr feed for questions and comments from other users about the app under review to get more perspectives than just my own. What are the common pain-points other users are having? What do they love about the app? What features would they like to see added?

Are there other sections you would like to see me add before I start dropping reviews? Get them to me soon, because I am currently taking notes for my first review, which will be the #Primal #Android client!

PV 🤙

@ 3bf0c63f:aefa459d

Buying versus donating

Currently (and probably it has always been the case) in the Bitcoin community there is some push towards donations as some sort of business model, or in general just a general love for the idea of donations, and I think that is very misguided.

Two examples of the push for the primacy of donations

For example, there is a general wantness of people to have some sort of "static QR code" or "static Lightning invoice" that people can put on their Twitter profiles to receive donations (sometimes they say "payments" instead of "donations" but to me there is no such a thing as a payment without a good or service being given in exchange, so I'm saying "donations") and that is a hard problem to solve considering the fact that most Lightning wallets are running on phones.

Another example is the "Podcasting 2.0" initiative that tries to integrate podcast players with Lightning wallets so they can send donations to podcast hosts that are running Lightning nodes. Their proponents call it "value for value" (or "value4value", "v4v") and if you ask they will say value4value is a "model" in which the listener gives out in satoshis to the podcast host the same amount of "value" he is getting from listening to that content.

The value4value concept makes it almost explicit the problems I see with this big emphasis on donations the Bitcoin community is making in general. In essence, the idea that the listener is capable of measuring the value it gets from the podcast then converting it into a monetary amount and then donating that is completely wrong and even nonsensical.

Why value4value is not sound

Basic (Austrian) economics teaches us that all value is ordinal, not cardinal -- i.e., it can't be measured or assigned a number to. One can only know that at some instant they prefer x over y, they cannot say x has a value of 10 and y has a value of 9. Because of that, it's a nonsense quest to try determine how much value one is getting from a podcast.

Basic (Austrian) economics also teaches us that exchanges happen when there are differences in the subjective valuations of goods, i.e., Alice can give x to Bob in exchange for y if Alice prefers y over x and Bob prefers x over y at that point. Because of that (and disregarding the previous paragraph), it's futile to expect that the podcast listener will donate exactly the amount he is getting from the podcast in "value".

Because of the two points above, it should also be clear that it is impossible to convert "value" in podcast content form into "value" in satoshis form, but I won't try to explain why that is because this is not an economics textbook.

What actually happens is that whether it's in the value4value context or not, donations are always a somewhat random and subjective amount, if they happen. If I like some content that someone is publishing for free, my decision on if and how much I will donate is never dictated by some nonsense calculation, but by calculation that is governed almost entirely by feeling and animal spirits (but one that also considers how much money I can spare, how much I like that person and how much I perceive they need).

When I go to a normal shop to buy a bottle of milk I look at the bottle of milk and I read its price, and there is one simple decision I have to make: is this bottle of milk worth more than the amount of money that's specified in the price tag? It's a single decision with only two answers: yes or no.

While when I see a free form on some free "creator" page asking me to type how much I will donate I have to decide if I will donate, when I will donate, how much I will donate, if I want this donation to be done every month or how will that work going forward? Will I keep consuming the content produced by this person? Will they keep producing? Maybe I'll just listen for free now and do this later as I'm busy, but then will I forget? Maybe I have just donated a lot to someone else and do not have much more money to spare, but now I feel guilty that the other person got all my donation money and this one didn't get anything but I can't go back and ask the other to return the money I just donated -- and so on and so forth.

Conclusions

Although the paragraphs above are confusing and do not follow a very logical presentation pattern, I hope you got from them why I think donations are much more complicated than purchases, and that repeating the "value for value" mantra doesn't help at all.

Considering that, what I wanted to say is that bitcoiners should give more attention to the other model, in which people produce goods and services and sell them. And that model can be applied successfully to "content creators", podcasters etc in many ways that are probably (I don't have any data backing my claims) better than the donation model.

Other possible monetization possibilities

For example, I've noticed that many blogs and podcasts with interesting content start to release exclusive episodes as they get big enough. These exclusive episodes are available only for "supporters". This is effectively selling access to the episodes. There is also the "crowdwall" model in which multiple people pay so that some content gets released for free.

We can count even the model in which a donation is not just a blank donation, but gives the donor the right to write something on the screen or something like that -- these are actually not just donations, but purchases of these rights.

Professional videogame streamers have come up with some other interesting ideas. For example, they crowdfund the creation of special content ("if enough people pay I will dress like a rabbit") or they sell the right to participate in the stream somehow (for example, by playing a game with the streamer in some special day).

In these models, the static QR code with which so many people dream doesn't make much sense (if you're selling a specific episode or if a payment is specific to one identifiable person, you need different QR codes or more metadata to be attached to each payment by the payer).

Addendum

I think people like the donation model very much because they only see the big and super famous people that receive donations. A very small set of people have so many followers that they can live with just donations, even though donations are very inefficient and they could earn more and even deliver better content if they were using some other model.

I imagine that a creator with a high number of followers will get a lot of people that do not donate anything, a lot that will donate a little -- probably less than they would if they were paying -- and eventually a little number of people that will donate way more than they would if they were buying. This last group is probably what makes it worthwhile to work on this donations model for these creators.

The takeaway is that the donations model is not a panacea and is not very good either.

Related:

• Donations on the internet

@ 62a6a41e:b12acb43

War is rarely (or if ever) the will of the people. Throughout history, wars have been orchestrated by political and economic elites, while the media plays a key role in shaping public opinion. World War I is a clear example of how propaganda was used to glorify war, silence dissent, and demonize the enemy.

Today, we see similar tactics being used in the Ukrainian War. The media spreads one-sided narratives, censors alternative views, and manipulates public sentiment. This article argues that wars are decided from the top, and media is used to justify them.

---

How the Media Glorified and Propagated WW1

The Media Sold War as an Adventure

Before WW1, newspapers and propaganda made war seem noble and exciting. Young men were encouraged to enlist for honor and glory. Posters displayed slogans like “Your Country Needs You”, making war look like a duty rather than a tragedy.

Demonization of the Enemy

Governments and media portrayed Germans as "barbaric Huns," spreading exaggerated stories like the "Rape of Belgium," where German soldiers were accused of horrific war crimes—many later proven false. Today, Russia is painted as purely evil, while NATO’s role and Ukraine’s internal conflicts are ignored.

Social Pressure & Nationalism

Anyone who opposed WW1 was labeled a traitor. Conscientious objectors were shamed, jailed, or even executed. The same happens today—if you question support for Ukraine, you are called "pro-Russian" or "anti-European." In the U.S., opposing war is falsely linked to supporting Trump or extremism.

Fabricated Stories

During WW1, fake reports of German soldiers killing babies were widely spread. In Ukraine, reports of massacres and war crimes often circulate without verification, while Ukrainian war crimes receive little coverage.

---

How the Media Promotes War Today: The Case of Ukraine

One-Sided Narratives

The media presents Ukraine as a heroic struggle against an evil invader, ignoring the 2014 coup, the Donbas conflict, and NATO expansion. By simplifying the issue, people are discouraged from questioning the full story.

Censorship and Suppression of Dissent

During WW1, anti-war activists were jailed. Today, journalists and commentators questioning NATO’s role face censorship, deplatforming, or cancellation.

Selective Coverage

Media highlights civilian deaths in Ukraine but ignores similar suffering in Yemen, Syria, or Palestine. Coverage depends on political interests, not humanitarian concern.

Glorification of War Efforts

Ukrainian soldiers—even extremist groups—are painted as heroes. Meanwhile, peace negotiations and diplomatic efforts receive little attention.

---

War is a Top-Down Decision, Not the Will of the People

People Don’t Want Wars

If given a choice, most people would reject war. Examples:

• Before WW1: Many workers and socialists opposed war, but governments ignored them.
• Vietnam War: Protests grew, but the war continued.
• Iraq War (2003): Millions protested, yet the invasion went ahead.

Small Elites Decide War

Wars benefit arms manufacturers, politicians, and corporate interests—not ordinary people. Public opposition is often ignored or crushed.

Manipulation Through Fear

Governments use fear to justify war: “If we don’t act now, it will be too late.” This tactic was used in WW1, the Iraq War, and is used today in Ukraine.

---

Violence vs. War: A Manufactured Conflict

Violence Happens, But War is Manufactured

Conflicts and disputes are natural, but large-scale war is deliberately planned using propaganda and logistical preparation.

War Requires Justification

If war were natural, why does it need massive media campaigns to convince people to fight? Just like in WW1, today’s wars rely on media narratives to gain support.

---

The Crimea Referendum: A Case of Ignored Democracy

Crimea’s 2014 Referendum

• Over 90% of Crimeans voted to join Russia in 2014.
• Western governments called it "illegitimate," while similar referendums (like in Kosovo) were accepted.

The Contradiction in Democracy

• If democracy is sacred, why ignore a clear vote in Crimea?
• Other examples: Brexit was resisted, Catalonia’s referendum was shut down, and peace referendums were dismissed when they didn’t fit political interests.
• Democracy is used as a tool when convenient.

---

VII. The Libertarian Case Against War

The Non-Aggression Principle (NAP)

Libertarianism is fundamentally opposed to war because it violates the Non-Aggression Principle (NAP)—the idea that no person or institution has the right to initiate force against another. War, by its very nature, is the ultimate violation of the NAP, as it involves mass killing, destruction, and theft under the guise of national interest.

War is State Aggression

• Governments wage wars, not individuals. No private citizen would naturally start a conflict with another country.
• The state forces people to fund wars through taxation, violating their economic freedom.
• Conscription, used in many wars, is nothing more than state-sponsored slavery, forcing individuals to fight and die for political goals they may not support.

War Creates Bigger Government

• War expands state power, eroding civil liberties (e.g., WW1's Espionage Act, the Patriot Act after 9/11).
• The military-industrial complex grows richer while taxpayers foot the bill.
• Emergency powers granted during wars rarely get repealed after conflicts end, leaving citizens with fewer freedoms.

Peaceful Trade vs. War

• Libertarians advocate for free trade as a means of cooperation. Countries that trade are less likely to go to war.
• Wars destroy wealth and infrastructure, while peaceful trade increases prosperity for all.
• Many wars have been fought not for defense, but for economic interests, such as securing oil, resources, or geopolitical power.

Who Benefits from War?

• Not the people, who suffer death, destruction, and economic hardship.
• Not small businesses or workers, who bear the burden of inflation and taxes to fund wars.
• Not individual liberty, as war leads to greater state control and surveillance.
• Only the elites, including defense contractors, politicians, and bankers, who profit from war and use it to consolidate power.

Conclusion: The Media’s Role in War is Crucial

Wars don’t happen naturally—they are carefully planned and sold to the public using propaganda, fear, and nationalism.

• WW1 and Ukraine prove that media is key to war-making.
• The media silences peace efforts and glorifies conflict.
• If people truly had a choice, most wars would never happen.

To resist this, we must recognize how we are manipulated and reject the forced narratives that push us toward war.