Repository navigation
Native Developer Collaboration Layer (Powered by Nostr) #25
Description
Problem
Currently, when a developer hits a roadblock on a Pull roadmap or project, the natural friction is to context-switch out of the platform into out-of-band communication channels (Discord, Telegram, etc.). This fragments knowledge, breaks developer flow, and traps valuable Q&A inside closed, ephemeral silos rather than building a searchable, SEO-friendly knowledge base for future builders.
proposed Direction
I propose adding an in-band collaboration feature directly attached to specific roadmap steps, project constraints, and tools. Instead of building a heavy, centralized forum backend, this collaboration layer could be built natively on freedom-tech protocols to align with Pull's ecosystem ethos:
Nostr-Powered Discussions: Leverage Nostr for the underlying communication layer. Developers can authenticate via NIP-07 browser extensions, keeping their identity portable. Comments, questions, and code snippets would be standard Nostr events tied to a specific Pull project URL or reference tag.
Reputation Integration: Pull's builder portfolios can index this public activity. Helping peers debug issues becomes a measurable metric for a developer's reputation score, proving communication, collaboration, and mentorship skills alongside raw code commits.
Who benefits most?
Everyone
Extra context
No response
Activity
[-]Native Developer Collaboration Layer (Powered by Nostr & Lightning)[/-][+]Native Developer Collaboration Layer (Powered by Nostr)[/+]Megasley commentedon Sep 8, 2026
Hi Denver, I really appreciate you writing this up, the problem you're describing is real. Knowledge getting stuck in threads outside of pull instead of building toward something searchable for future builders is exactly the kind of gap worth closing, and tying it to a specific roadmap step or project constraint (instead of a generic forum) feels like the right shape.
One thing I'd love to think through together: going Nostr-first for the underlying layer. A couple of things give me pause, curious what you think;
What if we shipped a native version first, comments/Q&A attached to a roadmap step, project, or tool, using the auth we already have, so it's fast to build and searchable from day one? The reputation piece you proposed is great either way and would work the same regardless of transport, since it's really just "credit for helping peers debug," alongside PRs and milestones.
Nostr could still make a lot of sense as a bridge down the line, mirroring native comments out as Nostr events for portability once the core feature's proven out. Would love to hear your take on that framing, and happy to dig into what a native v1 could look like together if it's useful.
mk-Denver commentedon Sep 9, 2026
Totally agree , native v1 sounds like the right place to start.
I was excited about Nostr because of the openness and portability, but you’re right that it probably adds too much complexity upfront for where we are right now.
The core goal is making collaboration searchable and useful inside Pull from day one, and a native implementation gets us there faster with less friction. I still like the idea of Nostr as a future bridge once the feature is proven, but I’m fully aligned on shipping native first.
Megasley commentedon Sep 10, 2026
Thank you.. I am glad we're aligned. Let me write down what "native v1" actually covers so this is buildable rather than just directionally agreed.
Proposed v1 scope:
Acceptance criteria (draft, open to reshaping):
Nostr-as-bridge (mirroring native comments out as signed events for portability) stays on the radar as a fast-follow, but out of scope for v1.. I'll track that separately if/when we get there so it doesn't block this.
@mk-Denver, what do you think about this?
mk-Denver commentedon Sep 11, 2026
Sorry for late reply @Megasley , the proposed scope is good to start implementing .I'm imagining more Idea on the shape and structiure will come once implementation starts.
Megasley commentedon Sep 11, 2026
Thank you @mk-Denver, I will work on this over the weekend.
Megasley commentedon Sep 12, 2026
Hi @mk-Denver, I have implement the first version as I proposed. Help me have a look on the website and let me know what you think?
mk-Denver commentedon Sep 13, 2026
This is a great start @Megasley ! Two features I'd love to see added to make the collaboration layer much more usable for developers;
Markdown editor with live preview : so people can quote questions, write formatted text, and include fenced code blocks easily. Syntax highlighting for code blocks and a simple toolbar (bold/italics/quote/code/insert link) would make sharing examples and work‑throughs much smoother.
Post editing with history : let users edit their posts after publishing (and show an “edited” timestamp). Ideally include a lightweight edit history or the ability to view/restore previous versions so context and accountability are preserved.
Why these matter: they reduce friction when sharing reproducible examples and keep discussions readable and searchable.
Suggested acceptance criteria
Megasley commentedon Sep 13, 2026
Hi @mk-Denver , thank you again for such thoughtful feedback, both ideas would genuinely make the v1 experience much better.
Good news on the second one: editing already works behind the scenes (there's already an edit action and an "edited" timestamp saved in the database). We'd just need to surface it properly in the interface, so this part should be quick to deliver.
For version history, would it be okay if we started with something simple: letting people view what a comment looked like before it was edited? I'd love to hold off on adding a "restore" button for now, since it brings extra complexity (who's allowed to restore, tracking those changes, etc.) for something a simple view of the previous text mostly already covers. Of course, happy to revisit this if it turns out to be something people really need.
The markdown editor is the bigger piece, and I want to be honest with you about the scope. Right now, comments are plain text by design... they're never rendered as HTML, which is what keeps everything safe from injection. Supporting markdown would mean carefully choosing a way to safely format text, adding syntax highlighting for code, and building the live preview. It's a meaningful piece of work, so I'd prefer to treat it as its own dedicated follow-up rather than bundling it with the editing/history changes.
With that in mind, here's what I'd propose:
Would this order work for you? And please let me know if the markdown editor feels more urgent than I'm assuming, I am happy to reprioritize.
mk-Denver commentedon Sep 14, 2026
@Megasley, I think your proposal is excellent. I'd be happy to help implement the markdown editor and submit a PR for review. I've noted the security concern regarding HTML injection and will prioritize that consideration during implementation.
Megasley commentedon Sep 23, 2026
Hi brother, apologies for late response. I've been busy with our Bootcamp. Yes please, I'd really appreciate a PR for this, thank you very much. @mk-Denver
mk-Denver commentedon Oct 5, 2026
Hello @Megasley I have submitted PR #48 for review
Megasley commentedon Oct 5, 2026
Hi @mk-Denver, thank you very much. I will review and give you feedback.
Megasley commentedon Oct 8, 2026
Thanks again @mk-Denver , I have merged #48
Do you think I can close this issue now?
mk-Denver commentedon Oct 8, 2026
Yes✅️