He is on the right direction, Ethereum is a bad choice thoug...

930ccef12372dd2f...

npub1jvxvaufrwtwj79s90n79fuxmm9pntk94rd8zwderdvqv4dcclnvs9s7yqz

hex

9529e21b8bfd5cba0b4aaf11cd12fe0a5db2f20657df7dbacf582411bb2fb255

nevent

nevent1qqsf220zrw9l6h96pd927ywdztlq5hdj7gr90hmaht84sfq3hvhmy4gprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekgnap8sv

Kind-1 (TextNote)

2026-04-20T18:49:55Z

↳ Reply to Technical Debt (npub14w4qnk43lsllls2qnldj3vfcxtx5qvtsf3xlvxv9yha8afrxhmfqju3rwx)

Yeah a long form note would be easier to follow, this thread gives an overview nostr:nevent1qqs9x9dy9fn23gq83xpsz53ln3439wt60aw4dddhptsy55pdts2mxegzyr...

He is on the right direction, Ethereum is a bad choice though, and Nostr is even worse choice. This is a common problem with Nostr users and Devs, they use it as a shortcut to avoid building their own gossip protocol, even though in this case the data is scarce enough that a gossip protocol is simple.

I am not sure he has a delayed rotation of the recovery key with the custody key as Farcaster IDs do or not but it is easy to add.

Few things are worth pursuing like history compression with ZK proofs and merklization of the entire state...

There is some indication that he is considering supporting server subsidy of registration, which is definitely the correct direction and should be a first class flow in the protocol.

I am working on something like that in my free time on Rootstock

Raw JSON

{
  "kind": 1,
  "id": "9529e21b8bfd5cba0b4aaf11cd12fe0a5db2f20657df7dbacf582411bb2fb255",
  "pubkey": "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9",
  "created_at": 1776710995,
  "tags": [
    [
      "e",
      "861170a0d3153c48e2b55c8a9f7de1f46950993ee424843f071d07c4d6cfcbfa",
      "wss://relay.primal.net/",
      "root",
      "930ccef12372dd2f16057cfc54f0dbd94335d8b51b4e2737236b00cab718fcd9"
    ],
    [
      "e",
      "f2ff41c0a6b3cf2c1b0d063dc0c01614c1be22d97358dfc67218e99dd370bf9f",
      "wss://relay.damus.io/",
      "reply",
      "abaa09dab1fc3fffc1409fdb28b13832cd4031704c4df6198525fa7ea466bed2"
    ],
    [
      "p",
      "d1a61498f4b1dc26df0becd1a3e9e88f355fb614b771e8b5b277d0ff99a82a23"
    ],
    [
      "p",
      "50809a53fef95904513a840d4082a92b45cd5f1b9e436d9d2b92a89ce091f164"
    ],
    [
      "p",
      "abaa09dab1fc3fffc1409fdb28b13832cd4031704c4df6198525fa7ea466bed2"
    ]
  ],
  "content": "He is on the right direction, Ethereum is a bad choice though, and Nostr is even worse choice. This is a common problem with Nostr users and Devs, they use it as a shortcut to avoid building their own gossip protocol, even though in this case the data is scarce enough that a gossip protocol is simple.\n\nI am not sure he has a delayed rotation of the recovery key with the custody key as Farcaster IDs do or not but it is easy to add.\n\nFew things are worth pursuing like history compression with ZK proofs and merklization of the entire state...\n\nThere is some indication that he is considering supporting server subsidy of registration, which is definitely the correct direction and should be a first class flow in the protocol.\n\nI am working on something like that in my free time on Rootstock",
  "sig": "8cef8b3679ede70f6349bfd54df223952c93bdd06f796bce59e46f56564777a122ce970922a9bf362211e695e2e8e4643c328133ed6ff4138e94eb0fd5c3e05e"
}