Sovereign Sprout - #403
Sovereign Sprout#403
Conversation
Reframe Sprout from communications platform to project home. Add sovereign relay paragraph and Code section (git hosting, repo browser, branch channels, agent CI).
One relay. One domain. Your project lives here.
| `myproject.com` is your project. Not a GitHub org page that happens to have your | ||
| name on it. Not a Discord server that Discord could delete tomorrow. Your domain. | ||
| Your relay. One thing. |
| You type `myproject.com`. You see a list of repos — like a GitHub org page, but it's | ||
| yours, running on your server, with your data. You click one. You're at | ||
| `repoa.myproject.com`. The README renders. The file tree is there. Click into `src/` | ||
| and the code is syntax-highlighted. The clone URL sits at the top: |
There was a problem hiding this comment.
maybe more details than here, but we should support optional icons/avatars for projects similar to other tools. Probably a description as well.
There was a problem hiding this comment.
Yes! We can extend the tags in the repo message to do this
| A contributor files a bug. It lands in the forum. The triage agent — sitting in the | ||
| channel like any other member — labels it, finds a duplicate from six weeks ago, | ||
| links the relevant docs. This happens before a human reads it. The contributor gets | ||
| a response in seconds. The maintainer sees a pre-processed report, not a raw inbox. | ||
| They read the triage summary, confirm it's real, assign it. Thirty seconds of their | ||
| time instead of five minutes. |
There was a problem hiding this comment.
We could roll in features like Canny has too. So users can optionally upvote features and bugs so they get prioritized.
- Cut from 400 lines to 226 — removed GitHub pain points catalog, competitor comparisons, and community sentiment research - Focus on OUR vision: how a forge works on Sprout - Align with VISION.md and VISION_SOVEREIGN.md: - Content negotiation model (same URL serves HTML and git) - CI model (workflows orchestrate, agents do compute) - NIP-34 as metadata/discovery layer, git as transport - Status claims consistent across all three docs - Add cross-references to parent vision docs - New opener: forge workflow (push → CI → review → merge → archive) instead of trust-filtering vignette
baxen
left a comment
There was a problem hiding this comment.
Looks great, captures everything we've discussed!!
|
|
||
| ## The Project Model | ||
|
|
||
| A project lives on the relay. `myproject.com` in a browser shows the project home. Click a repo and you're at `repoa.myproject.com` — README rendered, file tree navigable, code syntax-highlighted, clone URL at the top. The same URL serves HTML to a browser and git protocol to `git clone`. Content negotiation. One URL, two audiences. |
There was a problem hiding this comment.
nit: "The relay is the project"
confused me for a second, as i don't see a way for one relay to have more than one project with this description - want to make that clear as we implement it'll change the data models
| is a signed event. You can see it. You can weight it. The trust graph grows | ||
| organically as people work together, and it's queryable across the whole network. | ||
|
|
||
| This matters especially for agents. An agent with a persistent keypair and a |
There was a problem hiding this comment.
this points us in a direction that I think I like, where we move away from one identity per agent per channel to a single identity per agent. still very lightweight to create, but also easy to persist.
| Push to merge, fully traced. Every step is a signed event. | ||
|
|
||
| ``` | ||
| Push CI Review Merge |
There was a problem hiding this comment.
this is right, but means we need a concept of branch protections in the relay. worth a mention that they exist and that they go in the relay itself?
another way to do this - that i think is not what we intend - is to have the canonical remote owned by a person, not the relay, and the merge request is handled by the client who merges it into the owner's canonical URL. we could look at that later - some upside in that the project survives the relay if it ever goes down
… NIP-OA agent auth - Rename tagline from 'The relay is the project' to 'The relay is the workspace' (addresses multi-project relay confusion from review) - Add branch protections to The Project Model NIP-34 example (sprout-protect tags: push-allowed, require-approval, no-force-push) - Document NIP-OA agent auth model: agents inherit push access from their owner's permissions via auth tag, no per-agent config needed
One relay runs your entire workspace. Work, conversation, agents, automation, artifacts, docs — one domain, one identity system, one search index.
VISION.md
VISION_SOVEREIGN.md (new)
VISION_PROJECTS.md (rewritten)
sprout-protectNIP-34 tags — push-allowed, require-approval, no-force-pushReview feedback addressed: