盗品を盗品と知らずに貰い受けてしまって、さらにそれを、売却した時、その人が犯罪になるのか？という議論ですね。

犯罪の打ち合わせをするためにOpenSlotsが使われた時の議論が必要だろう、という批判はあると思いますね。 開発者の僕はもちろん、リレー運用者にも。 道徳・倫理・法律の面で、個々の議論はあると思いますが、暗号化されたものを流通させることに関しては、「善意の第三者」という解釈が適用されると思います。 https://fujisawa.vbest.jp/columns/general_civil/g_lp_indi/7515/

みんな、断られる未来しか、考えてなくて、これまでの人生が透けて見えますねぇ。（炎上マーケティング）

ちなみに僕は両方とも０％なので同じ確率です！

前者は、「日時とイベント」の両方の可否を聞いていますが、実は後者は「イベント」はOKの前提のもとで「日時」のみ可否を聞いていますね。

気になる異性をデートに誘う時、「来週の土曜日映画を見に行かない？」と「映画を見にいきたいんだけど、いつ空いてる？」の成功率の違いを考えてみてほしい。（ただし、嫌われていないものとする）

リレー運用側の意見きけて勉強になります！ゆくゆくは openslots 自身の リレーも用意する覚悟です！

ただ調整さんとかを仕事（に近いシーン）で使おうとすると、名前とか適当なハンドル名にするとはいえ、集合時間とかの個人情報がサーバーにのるのが、ちょっとまずいよなーと。なのでマルっと暗号してしまえば、安全だなと思いついて作りました。

仕事仲間と打ち合わせの調整するときに、どの時間が空いているかを、互いに調整する必要があって、その場合、「候補日を決めて伝えなくちゃいけない」「相手も空いてそうな時間を選ぶ」という空気読みが発生するんですが、When2meetとかだと、雑に二週間選んで送りあって、適当に色を塗ると、濃くなる場所が出てきて、それを打ち合わせに採用する、という使い方ですね

グラデーションの色もっと濃くした方が良さそうですね

I built OpenSlots, a zero-knowledge scheduling application that works without a trusted server. 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. Key ideas: - No trusted third party: Runs as a browser-based thick client. Nostr relays are used only as untrusted storage. - End-to-end encryption (NIP-44): All room data and availability are encrypted with ChaCha20-Poly1305. - URL fragment key distribution: The symmetric room key lives only in the URL fragment and is never sent to servers or relays. - Blinded indexing: Room identifiers are indexed on relays via HMAC-SHA256(room_id, key), preventing trivial enumeration or mapping by relays. 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. This is not full anonymity: IP addresses and timing remain observable. The goal is trust minimization and metadata reduction, not network-layer anonymity. Demo and documentation: https://openslots.pages.dev Technical Details: https://github.com/tani/openslots Feedback is welcome, especially on the threat model, blinded indexing design, and usability trade-offs of URL-as-bearer-key approaches.