GistStr:
Things can happen separately.
1. Build git commit Nostr transport/integration, ideally local “git” can see a relay url as remote.
2. “pull requests” could probably be done with replies to a commit reference as comment.
3. Pm/Social features like “issues” can be done as separate Nostr tool that have GitStr integration. This could just be multiple Nostr PM tools solutions with GitStr integration.
So you’re building it?
You have the domain?
WeAllBuilding.
All-in-one decentralized GitHub synced across relays with an ION domain or ZeroSync domain > GitHub split into multiple tools hosted on a centralized domain.
Relay syncing allows for GitHub search competitive with the existing one. Users can’t connect to hundreds of relays on Damus, let alone on GitHub where files are larger.
If relays sync, users can connect to a handful of relays to search through them all.
Highlighter will be great for PRs
#[3] thoughts? I don’t think it’s the right solution. #[4] #[5] #[6] What you guys think of my OP?
I mean for comments on code in addition to 2.
Yeah, I think highlighter or something like that would have small utility to organize your personal/team work around PRs/commits/issues etc
I personally don’t like at all the approaches of solving “github” within a single team/approach/top-down
I’m much more bullish on tools that interoperate to solve the “github” use case (which is a collection) of use cases
Nostr gives you interoperability for free; the idea of building a single solution that does it all I think kinda misses the point.
Bullish on giststr.
Microapps approach allows innovation in all levels and going deeper & more specialised when new ideas and needs arise.
Currently building something for nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s git patch
1. Just need `nevent`, like `git checkout nostr:nevent1xxx`
2. nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s already built something for this
3. Yes
Yup, this is it
Point 1 was my shower thought yesterday morning. Relays as remotes will take us a long way.
Framing the problem as “replace github” is not as useful as applying Unix methodology and solving for one problem at a time.
