Today I am proposing a NIP that will enable users to share, authenticate, and version third-party objects using Nostr. It is intended to serve as a foundation for functionality akin to GitHub, SharePoint, and Google Drive, among other use cases.
More thoughts in the thread.
The obvious way of doing Git on Nostr is to use the relays as file servers and Nostr events as commits, pull requests, issues, etc. This is overkill. Git is already a distributed blockchain; if it ain't broke, don't fix it.
So then the question is, what does GitHub provide that makes it so valuable?
As far as I can tell, GitHub offers developers three key value propositions:
1. Discoverability
2. Authentication
3. Hosting
1. Discoverability
Anyone can easily find and contribute to GitHub-hosted projects. GitHub repos show up as the first results in web searches. It's the one-stop shop for code collaboration.
2. Authentication
GitHub centrally manages identity. If you have an account, everyone knows who you say you are, and can trace your commits back to your profile. Trust in GitHub as a platform facilitates trust in the developers who use it.
3. Hosting
GitHub offers free repository hosting on the web. For no cost, a developer can dump any number of projects of any size onto GitHub's servers, and know they'll be available whenever they are needed.
So how does Nostr fix this?
1. The NIP I've proposed ties objects to server hints that indicate where they can be found. Making even highly distributed or decentralized hosting schemes readily discoverable.
2. On Nostr, your keys are your identity. This NIP allows you to put the weight of your Nostr identity behind a third-party object, such as a Git commit. If I trust you, I can trust your commits.
3. Git can turn any computer into a repository host, and it supports collaboration with multiple upstream repository sources. We don't need to turn Nostr relays into file hosts. Instead, this NIP simply associates objects with their host address, allowing you to verify any repository source and incorporate it into your web of trust.
So, the core concept is simple. I put an object on a server somewhere, and I want other people to know that it's legitimate. Using this NIP, I create an event that identifies that object, tells others where to find it, and attests to it with my Nostr identity, all at once.
Beyond just Git, this NIP can form the basis of SharePoint or Google Drive services, software release verification, authentication of images, and many other use cases besides. The only limit is imagination.
So this proposal would only verify that a URI is associate with an npub, but not sign for the content located at the URI. Even if content changes, verification remains in tack until revoked “manually”. Is this correct?
The proposal contains the suggestion that the note contain a hash of the object referred to.
I can imagine using this to have multiple people "sign off" on a document or a change to a document, like a social media note, an advertising image, or a new version of a company webpage.
You could simply have pull-requests run on any object identified by the PR, before it be considered "released", and define who has to approve the PR.
If you use a simple ID, then you can replace the contents at that URI without breaking the association. In that case, the even attests to a URI more so than an object.
If you use a hash of the object as the ID, then you can validate the object, even if it moves, at any number of URIs.
So can serve dual purpose… nice. But how does a client know which kind ID an event is using? Is there a standard verifying what the decrypted hash “should” equate to?
If you create an event that uses a hash-based identifier, the protocol requires you to include the name of the hashing algorithm you used as an event tag. So a client could read the event, download the object from the URI, run the specified hash function (e.g., SHA-256), and compare it to the ID of the Nostr event. It's kind of like a checksum.
Right. Now this is a bit out of my wheelhouse… but I do imagine such verification could be needed on other “not single object” web accessible data. Namely, descrete content embedded (and only accessible) within an HTML page.
EG:
Suppose a nostr user wants to verify a single post on a shared blog. Such a blog may have sidebar and footer data that changes periodically. The page content cannot be verified, but the post content could be.
Would this proposal suggest a “standard” by which “verifiable data” could be discovered at such a URI with mixed data?
I'm hesitant to prescribe a particular solution, because any number of possible situations and solutions may exist for what you are describing.
One very simple approach would be to provide some additional verification details in the `content` field of the event. My proposal doesn't make any requirements on what must be in the `content` field, so a client for verifying a web page could give a specific URI, like "myblog.com/post1#section" to sign that specific section of the page. The in the content of the event, a copy of the content of that section of the page could be provided. If it changes at the source, that would be immediately apparent to the client.
Thanks. I wonder if this should be specified with more detail in order for this NIP to fit “many other use cases besides. The only limit is imagination.”
You could then run an enterprise search engine over a relay and be able to find objects, like an Internet search machine, and rate how relevant or trustworthy they are.
Instead of Google PageRank, you could have Nostr SignRank.
My dream would to be able to ⭐ people's software releases. I'm always getting asked which software I recommend in which version and I'd like to have a list of everything I'd favorited or rated or whatever.
And I'd like to be able to see the ratings my favorite developers, testers, and power users have given. Then I could see what they'd ⭐, check it out and maybe add my own star.
2 ⭐ confirmations
45 ⭐ confirmations
147 ⭐ confirmations
Now, show me the most-⭐ repos in category "budgeting" or "Bitcoin memes". Show me the trending repos (those most actively receiving stars). Etc.
I think it's quite revolutionary because, until this NIP, you had to go to a particular website to ⭐ stuff. Now you can ⭐ anything, anywhere you can point to it with some sort of internet identifier, using any client that writes and signs ⭐ notes, and your star can be evaluated by anyone reading from any relay you've written your ⭐ to.
You can star Beave's Blacksmithy webpage, Beth's Baked Goods e-bay site, Vitor's Amethyst release, Michael's newest NIP, whatever.
More so than these, imo, the standardization of contributing to a project was far more valuable.
Everyone knows how to open an issue, fork a project, and open a PR. GitHub Flow became a common pattern that devs could use as a common reference.
Otherwise GitLab and BitBucket would be just as big as GitHub.
I used to use Bitbucket and issues were more in JIRA.
Fair. Framing this proposal as nostr solution for the entire GitHub value prop is a bit presumptuous.
But there IS value for nostr in having an implementation possibility wherein users can verify external resources.
The proposal isn't the full solution, it's the technical specification of the NIP required for the solution.
This proposal doesn't provide the entire GitHub value proposition by itself. It needs a substantial application to be built on top of it.
It was inspired by thinking through how we could support GitHub using Nostr, hence the thread. I want others to be able to follow the thought process.
The long-term goal is to use this NIP to enable that exact GitHub workflow using Nostr identity with a distributed backend.
Awesomesauce!!
Boosting this one more time for visibility. Stay tuned; there is an app that use this NIP in the works.
