2024-08-31T21:26:07Z https://njump.edufeed.org tiero https://njump.edufeed.org/npub1w4sf3hsedukh33akdn5duld2yc5jlk6s02shur8553j0a59sm3jscws08a https://pbs.twimg.com/profile_images/1546906058798600192/RC0uPLKP_400x400.jpg https://pbs.twimg.com/profile_images/1546906058798600192/RC0uPLKP_400x400.jpg https://njump.edufeed.org/nevent1qqsgkcqugrfmrpd02aqpupgq694veq5af7a0z67pakn6sxu2gx20gjczyp6kpxx7r9hj67x8kekw3hna4gnzjt7m2pa2zlsv7jjxflkskrwx2y8evhw Interesting <blockquote class="border-l-05rem border-l-strongpink border-solid"><div class="-ml-4 bg-gradient-to-r from-gray-100 dark:from-zinc-800 to-transparent mr-0 mt-0 mb-4 pl-4 pr-2 py-2">quoting <br/><span itemprop="mentions" itemscope itemtype="https://schema.org/Article"><a itemprop="url" href="/nevent1qqsrst3ks4wt3rny5m2gr6rfqrfggf3unxpur6rkmn2355cahv6gneqpp4mhxue69uhkummn9ekx7mqygtlke" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1">nevent1q…tlke</a></span> </div> I built OpenSlots, a zero-knowledge scheduling application that works without a trusted server.<br/><br/>Most scheduling tools (When2meet, Doodle, Calendly, even self-hosted ones) leak significant metadata: who meets whom, when, and how often. OpenSlots treats scheduling as a client-side protocol rather than a hosted service.<br/><br/>Key ideas:<br/><br/>- No trusted third party: Runs as a browser-based thick client. Nostr relays are used only as untrusted storage.<br/><br/>- End-to-end encryption (NIP-44): All room data and availability are encrypted with ChaCha20-Poly1305.<br/><br/>- URL fragment key distribution: The symmetric room key lives only in the URL fragment and is never sent to servers or relays.<br/><br/>- Blinded indexing: Room identifiers are indexed on relays via HMAC-SHA256(room_id, key), preventing trivial enumeration or mapping by relays.<br/><br/>Relays can observe ciphertexts, tags, and timing, but cannot read meeting content or recover room identifiers without the key. This removes the central database as a point of trust.<br/><br/>This is not full anonymity: IP addresses and timing remain observable. The goal is trust minimization and metadata reduction, not network-layer anonymity.<br/><br/>Demo and documentation: <a href="https://openslots.pages.dev">https://openslots.pages.dev</a><br/><br/>Technical Details: <a href="https://github.com/tani/openslots">https://github.com/tani/openslots</a><br/><br/>Feedback is welcome, especially on the threat model, blinded indexing design, and usability trade-offs of URL-as-bearer-key approaches.<br/> <br/> <img src="https://image.nostr.build/ea7b60d80a526aa8f4c40c53be1f095349752b4a01dc0de1d7058ee30be07311.png"> </blockquote> 2026-01-14T18:25:36Z https://njump.edufeed.org/nevent1qqs8mt6v40u2nse3jyqeaqe39jyke08ytufy58cek992kqdjm6snnhszyp6kpxx7r9hj67x8kekw3hna4gnzjt7m2pa2zlsv7jjxflkskrwx2c832wt Coin control is fundamental for #bitcoin transactions privacy, but it’s annoying to have to handle the change output and keep track/label on every spend.<br/><br/>What if merchants accepting bitcoin could let me create a simple payment channel address that can be funded spending an arbitrary amount of coin(s) without generating a remainder, hence no change output in the transaction?<br/><br/>User wallet would send funds and right away sign the initial state deducted of the first spend in favor of merchant <br/><br/>ie. <br/>Funding amount 0.1525 BTC<br/>First payment 0.01 BTC<br/><br/>It a basically the Bitrefill account balance, but with somewhat a guarantee you can get back your “gift card” if service is not delivered to you anymore. 2024-07-26T18:14:28Z