Nostr spec for quorum

Taylor Phillips wrote a PR for a spec for quorum on nostr.

You will definitely be interested in this @Josh_Ketry

This is relatively well written but I think it would be helpful to expand and fix the definitions, as well as clean the document… And I think this could benefit from defining the actual process of decision making as a tag, one of which could be swarming.

If we clean up this proposal, and start writing our own spec based on this (and create a SAIP-like thing) we can easily be cross compatible with plenty of future things happening on the str

1 Like

I am so far behind I have not even learned how to use Nostr yet. Any tips? I tried once but it seemed like it required technical knowledge.

Are you suggesting turning our existing code into a compatable tool for NOSTR? You use a lot fo tech speak I am unfamiliar with

Think of it like this: imagine if every phone manufacturer invented their own charging cable. You’d need a different cable for every device. USB became the standard so everything could “talk” to each other.

That’s what this PR above is. Essentially this spec provides a “universal way” to define how decentralized organizations can have members and representatives (if needed), vote on decisions, maintain transparent governance.

Essentially, given a decision, can we publish it in such a way that it’s cryptographically sound (i.e. it’s possible, for people that know what they’re doing, to know without a doubt that the decision that is published has been made by the people who can make that decision, and someone didn’t “pretend”). This method even allows working with higher levels of groups, like your swarm of swarms idea.

Essentially, how can groups be integrated with nostr, and how can the final decision be trustlessly broadcasted?


This spec is however missing a lot of things that would make it work with Swarming, and what we’re building with Swarm Force.

So my suggestion, and reason for this post is to improve onto the spec that this fellow wrote, make it work with what we have in mind with Swarm Force, so that it works with what we have in mind, and then later expand on it and build our own specs on top of it, creating our own spec, let’s say SAIP or “Swarm Academy Improvement Proposals”, similar to Nostr’s NIP “Nostr Implementation Proposals”.

Then the tool we build could potentially work with other Nostr-based tools in the future. It’s about interoperability; making sure different systems can talk to each other.

Are you suggesting turning our existing code into a compatable tool for NOSTR? You use a lot fo tech speak I am unfamiliar with

Rewriting the code is a part of it, I guess, but the main goal is speaking the same language as everyone else.