Jack Dorsey has set a 10 btc bounty for Nostr based alternative to GitHub
snort.social
snort.social
But asking for a github replacement seems like way too much scope. Github is millions of people-hours of work, does a crazy large amount of stuff.
Just start with some basics: can I get a stream of commits from someone? Can I send patches ("pull requests") to someone? Find some managable goals, and build protocols forwards.
The product minded "deliver me a complete replacement for a whole (& massive) product" is a harm-inducing act that obstructs incremental growth & genuine sucess. Nostr has NIPS, Nostr Improvememt Possibilities (NIPS)- trying to coax some wildcard team into writing either one massive NIPS and a huge product or a sea of closely interlocked NIPS and a huge product is going to cause longstanding damage & an inability to grow this organic system out right.
That's really it, servers have less authority in nostr, and that's why it's more resistant to censorship.
If your concern is private, if this were to find some kind of use you’d inevitably see shared blocklists just as we’ve seen for things like email spam. That’s a really important thing to study for any distributed system because “censorship resistant” inevitably means “full of spam, malware, and illegal content” unless you’re very careful designing some compromise to prevent that (e.g. IPFS mirroring is opt-in, so an innocent node owner doesn’t wake up to the FBI knocking their door in).
In the case of GitHub, anyone who wants to self-host an alternative can do so for only the cost of their time & modest app hosting resources running Gitlab, Gitea, etc. That raises the question of where this offer is coming from: there isn’t a notable problem with censorship on GitHub for otherwise legal content, so you’re mostly talking about things which are actually illegal and that means that something like Nostr isn’t changing the picture much because everything already is decentralized. If the Tornado Cash guys are on a block list, Nostr server owners are going to have legal demands to block their keys, too, just as a hosting company would get a take-down for a private GitLab instance.
If governments do try to get things removed on Nostr they're going to have a much much harder time. Folks can re-pop-up on different relays. Governments can keep playing whack-a-mole but I have hard time seeing they'll have any success. Your post makes it sound like a government can snap it's fingers & every relay will magically stop carrying content: that seems wildly out of touch to me, seems to be way different from what I'd expect when this situation crops up.
Not needing to host is a critical change of the game here, in my view.
The DNS system is decentralized and updates take seconds. We’ve seen this for decades with things like open source projects when someone gets tired of hosting it.
> Your post makes it sound like a government can snap it's fingers & every relay will magically stop carrying content: that seems wildly out of touch to me
Look at what happened with the TornadoCash guys — once legal action was taken, how many exchanges would allow transactions to or from their addresses? This would be similar: once enough people start using it, someone will do something illegal, and then governments are going to start telling server operators in their jurisdictions to stop allowing that traffic if they don’t want to be charged as accessories. Since those guys don’t want to go to jail or have their servers packed up by federal marshals, they’ll figure out whatever is necessary to block certain keys.
Something like Nostr might make it slightly easier to replicate things or provide a less antiquated key management system than GPG but it won’t be a game-changer but an incremental improvement at best.
I think this effort here is both overstating the problem of using GitHub and understating the challenges of replacing it. People use GitHub because running servers is a chore they don’t want to deal with. Relatively few people are donating hosting and the ones who do generally aren’t interested in hosting the few types of content which GitHub bans, either. They’re certainly not going to go to jail rather than help the police who tracked something illegal to their IPs.
DNS is hardly a good shield for dealing with potential takedowns. It seems obviously true for a variety of reasons, including some mandated takedowns at the centralized DNS layer itself. Relays obviously allow a vault potentially infinitely replicated way means for unhosting that simply lacks many good modern parallels.
TornadoCash again seems radically different from anything we are talking about, simply because it is so heavily in the highly regulatory financial regime, in a way that Nostro simply isn't. The government never really had to step in; the threat of it maybe having to made everyone change their tune very fast. And there just were very very very few actual decision makers involved. Nostr is far more decentralized in practice, even though the number of users is much lower than cryptocoin stuff.
Elsewhere I've agreed that replacing GitHub is really really hard & long work, & I've pined for us to take smaller steps rather than make such big totalizing attempts. But I think you don't really grasp the unhosting ideas& advantage. And you seem unwilling to deem any attempt worth starting. At some point the feelings against big centralized social networks leads us to trying new things, but I mostly read fatalistic why try from your people-dont-want-to-host-things, even though Nostr's whole point is to make being a relay at small interpersonal scales reslly easy, without having to tackle the hard big-scale computing hosting challenges. And if your relay goes down,... so what? Your small unhosted network is there.
> But I think you don't really grasp the unhosting ideas& advantage
This is why so many people are comparing this to blockchains/web3 — people seem to have started by saying everyone needs to adopt a particular technology but it’s like pulling teeth to get a proponent to give a concrete example of a real problem experienced by non-hypothetical people which is competitively solved by using it. If you ask for details the response is not to provide them but say “you don’t get it”, which in my experience is one of the most reliable indicators of a technology which will fail.
I first used self-hosted development tools in the 90s so assume I’m familiar with the advantages and disadvantages of working that way. What I’m missing here is a benefit from Nostr which would be so beneficial that people would give up the advantages of the systems everyone has settled on. For example, if the big pitch is “censorship resistance” I’d start by establishing who’s being censored on a scale noticeable enough to support a large development effort, followed by convincing analysis that the proposed system will actually accomplish its goals.
The infrastructure is decentralized, but it's one of the most centralized systems in the world, in terms of what's available/what you'll find.
> people seem to have started by saying everyone needs to adopt a particular technology but it’s like pulling teeth to get a proponent to give a concrete example of a real problem experienced by non-hypothetical people which is competitively solved by using it.
I think a lot of it is a pretty simple desire: we want to chat with each other, and be able to have access to the data. Literally no social media system on the planet actually lets you take your conservations out. You're limited to 24 hours of caching at most. If you quit or get banned, your words vanish. If someone else quits or gets banned, their words vanish. Memories up in smoke. With Nostr, the data is yours to do with.
In general I think there's a pretty obvious calling here, for people to have something/anything. Right now we literally have no option to start from, no ability to do anything or try other things, on any of the major incumbent systems. Your criticism seems very "no one can explain what it's for" conservative, but the progressives don't care about what it's for. We want something where we can figure out what it's for, we want a way to start to figure out what progress might look like. We need a starting place to explore what is possible.
There's already a ton of really neat & interesting NIPS. There's already social networks forming. We already can archive and relay our data, over any available medium including offline. There are interesting capabilities here which are unmirrored. I don't think anyone here is concerned about the normies right now: the alpha geeks want to serve themselves, want to build freedom & possibility, which is what's denied right now. They are building possible starting places we can adapt and adopt to many uses. And they're doing an excellent job, doing new things, that no one else can, in part because no one else can do anything at all (because giant megacorporations own all the other mediums)_and in part because they have good technical underpinnings with potentiate a much wider space of possibility than the limited centralized site-based hosting systems we have today.
Contrary to your shade, I don't think the Nostr people are fanatics about their tech. It's a starting place, that techies find to be a reasonably good place to start building exploring from. There's not a lot of contenders, to be honest. We need something, and very little else right now fits.
Progressives have goals. That doesn’t always mean solutions, but nobody should struggle to say what they’re trying to improve. That’s somewhat conspicuously absent in Dorsey’s bounty listing, and that’s why I’ve been asking.
Ultimately, the problem is that a service like GitHub or GitLab uses a fair amount resources to run. You have non-trivial storage needs, multiple separate systems making changes which aren’t a simple write-once structure (think about what git rebase does to your storage needs), and non-trivial services like CI. Most projects started out running those themselves (possibly starting in the CVS or Subversion eras), got tired of it and switched to something like GitHub, GitLab, BitBucket, etc. and in general that’s been a popular choice. They have paid services which generate a fair amount of revenue to support their businesses but the free tiers allow many open source projects to work without thinking about infrastructure.
This means the very first question I have is the still unanswered one: what is going to motivate someone to spend time working on this or take the risk of switching to it? Nostr isn’t designed for this problem so it’ll be harder to solve there and you’re still going to have to pay for servers since relays don’t guarantee storage unless you run them, and I don’t see very many people who are unsatisfied enough with the status quo that they’re going to donate millions of dollars worth of development time.
Average users arent about to sign up to a "Censor-Resistant Decentralized Social Protocol". Most people wont even have a clue what that means.
It seems to be the same people that were convinced NFT's were going to be big that are backing it.
Not at all. Most Nostr proponents are Bitcoin maxis that generally hate NFTs. They are groups of people that are more aware of the limitations of freedom of speech and free markets on a constantly centralizing internet and aim to solve the problem.
> seems to be the same people that were convinced NFT's were going to be big that are backing it.
No. It's quite the opposite.
> The absolutely retarded state of HackerNews (Then a screenshot of this HN thread, which is here: https://imgproxy.snort.social/48YuDDEW11PoCqbeQ8R25a0kGN3BJe...)
It's interesting how different social platforms foster little pigeon holes for people, that act almost as some kind of militant platoon. Weird.
Few people then saw that making the echo chambers bigger didn't improve them much.
If someone started a "hn is shit" thread, i suspect lots of people who frequent hn would disagree.
What does "read from global" mean? What is a "relay" and what is paid vs public? Why does FF suggest adding snort.social as an application for "web+nostr" links?
Messages are cryptographically signed, and users are identified by their public key. Users typically follow other users like they would on Twitter, but the client manages everything, so there is no dependency on any relay.
Messages are typically posted to many relays at once and clients typically read from many relays at once. Jack Dorsey's message is being displayed here because it was copied to a relay that this website has access to. The same message is accessible elsewhere.
"Global" means that you download all the public messages that a relay has, instead of just downloading messages posted by people you follow.
It's the same reason mastedon had a huge surge of signups followed by very little activity - nobody wants to screw around with technology that has crappy holes you have to jumpt through.
I swear every decentralised platform is aimed at a very tiny niche community who have no concept of UX or usability.
I still don't get how this is supposed to be better than activitypub.
I have been thinking about this problem space a number of times and after first thinking my ideas were significantly better I have come to understand why nostr picked this solution.
https://docs.github.com/site-policy/github-terms/github-term...
but then other people said its allowed:
https://docs.github.com/account-and-profile/setting-up-and-m...
they also killed every issue, pull request and comment that I have ever made, across several years.
I think it is important that we solve the problem of centralised social networks.
And I think Nostr has the right idea. Nostr differs from ActivityPub in that identity is not tied to the instance that you use.
To quote someone else:
> Nostr uses a public key to identify users, while ActivityPub utilizes a more conventional user account system. ActivityPub user accounts are based on domain names, which can be controlled by third-party entities. Nostr's identification system is more decentralized, as it does not rely on domain names controlled by outside parties.
https://dri.es/nostr-love-at-first-sight
I’m sorry to hear about your experience with GitHub banning your account and the stars, issues, PRs, comments and so on that you lost.
Hopefully in the future when a truly decentralised alternative to GitHub exists, other people can avoid that kind of experience.
An alternative to GitHub, in the shape that Jack Dorsey has put a bounty on here.
Would this entail creating a new VCS which has a server that communicates over nostr, as well as a GitHub-like frontend? Or just some nostr interface to git?
Personally, I wouldn't dare try to compete with GitLab, let alone try to take on GitHub, for a measly 10 BTC. But someone more optimistic than me might, and good luck to them.
I guess other people value the “social media” aspect of it more than I do? I don’t really care if I’m interfacing with github or gitlab or codeberg or huggingface or sourcehut or whatever. Git is git.
Like parent commenter said, this is about all of the other features of GitHub. The issues, the stars, the followers. The social network that MS paid $$$ for.
We need a decentralised alternative to GitHub that lets everyone do everything they are using GitHub for today, without the involvement of any big companies that rule over our social networks.
That is what Jack Dorsey is asking for. That is what we don’t have today.
We need a decentralised social network with GitHub features which makes it so that we can create an account anywhere and use that same account everywhere, across servers. So that there can be a billion GitHub alternative servers with all of the GitHub features, and you can communicate across instances without being beholden to the owners of any single one instance too much.
Jack Dorsey wants this to happen on top of the Nostr protocol specifically.
But yes, if you try to understand all of this from an angle of “git is git” then it might not seem to make sense. But that’s because it’s not about git. It’s about everything social around it.
In most of the open source circles I run in, people are pretty openly hostile to anything web3, so they probably would opt to stay on their alternative hosting platforms.
But perhaps there are enough web3 people to use it? I’m curious to see how it plays out and what kind of development takes place on there.
How do you think the bounty will play out, by the way? Will whatever is developed be open source? Who do you think will oversee maintenance?
Jack Dorsey paying for it with BTC or USD doesn't make it web3 or not.
I wish I had the skill to pull that off.
On, the other hand, Nostr as a distributed social network looks interesting in its own right.
The only minor problem I have with it is that the early adopters are very pro crypto/anti vaccines and it might give the impression that it is a community for such folks when in reality it seems to be just a much better technical alternative to smtp and nntp and (for some use cases) for xmpp for this century.
His money could save millions of people from starvation [0], but what is he trying to spend it on instead? A less useful alternative to an already existing service, for no reason other than supporting his neo-feudalist ideology.
Gross.
[0] https://www.wfp.org/stories/wfps-plan-support-42-million-peo...
10 btc = $22300
$0.43 = one basic meal per person per day.
(10x22300)/((0.43x3)x365) = 473
This would help 473 people a year with 3 basic meals per day.
It is a number greater than zero, which is good, but we're also not talking about huge amounts of numbers here either.
Let's re-allocate funds away from militaries and politicians who create needless wars and worry less about Jack.
* commoditize your complements :: hardware
* open source your complements:: software
* decentralize your complements :: ??? (Platforms maybe?)
https://gwern.net/complementSeems like some people already started projects to get the money: https://github.com/NostrGit
Events and signatures Each user has a keypair. Signatures, public key, and encodings are done according to the Schnorr signatures standard for the curve secp256k1.
The only object type that exists is the event, which has the following format on the wire:
{
"id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": <integer>,
"tags": [
["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
["p", <32-bytes hex of a pubkey>, <recommended relay URL>],
... // other kinds of tags may be included later
],
"content": <arbitrary string>,
"sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}
To obtain the event.id, we sha256 the serialized event. The serialization is done over the UTF-8 JSON-serialized string (with no white space or line breaks) of the following structure: [
0,
<pubkey, as a (lowercase) hex string>,
<created_at, as a number>,
<kind, as a number>,
<tags, as an array of arrays of non-null strings>,
<content, as a string>
]
Communication between clients and relays
Relays expose a websocket endpoint to which clients can connect.From client to relay: sending events and creating subscriptions Clients can send 3 types of messages, which must be JSON arrays, according to the following patterns:
["EVENT", <event JSON as defined above>], used to publish events.
["REQ", <subscription_id>, <filters JSON>...], used to request events and subscribe to new updates.
["CLOSE", <subscription_id>], used to stop previous subscriptions.
<subscription_id> is an arbitrary, non-empty string of max length 64 chars, that should be used to represent a subscription.
<filters> is a JSON object that determines what events will be sent in that subscription, it can have the following attributes:
{
"ids": <a list of event ids or prefixes>,
"authors": <a list of pubkeys or prefixes, the pubkey of an event must be one of these>,
"kinds": <a list of a kind numbers>,
"#e": <a list of event ids that are referenced in an "e" tag>,
"#p": <a list of pubkeys that are referenced in a "p" tag>,
"since": <an integer unix timestamp, events must be newer than this to pass>,
"until": <an integer unix timestamp, events must be older than this to pass>,
"limit": <maximum number of events to be returned in the initial query>
}
Upon receiving a REQ message, the relay SHOULD query its internal database and return events that match the filter, then store that filter and send again all future events it receives to that same websocket until the websocket is closed. The CLOSE event is received with the same <subscription_id> or a new REQ is sent using the same <subscription_id>, in which case it should overwrite the previous subscription.Filter attributes containing lists (such as ids, kinds, or #e) are JSON arrays with one or more values. At least one of the array's values must match the relevant field in an event for the condition itself to be considered a match. For scalar event attributes such as kind, the attribute from the event must be contained in the filter list. For tag attributes such as #e, where an event may have multiple values, the event and filter condition values must have at least one item in common.
The ids and authors lists contain lowercase hexadecimal strings, which may either be an exact 64-character match, or a prefix of the event value. A prefix match is when the filter string is an exact string prefix of the event value. The use of prefixes allows for more compact filters where a large number of values are queried, and can provide some privacy for clients that may not want to disclose the exact authors or events they are searching for.
All conditions of a filter that are specified must match for an event for it to pass the filter, i.e., multiple conditions are interpreted as && conditions.
A REQ message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as || conditions.
The limit property of a filter is only valid for the initial query and can be ignored afterward. When limit: n is present it is assumed that the events returned in the initial query will be the latest n events. It is safe to return less events than limit specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
From relay to client: sending events and notices Relays can send 2 types of messages, which must also be JSON arrays, according to the following patterns:
["EVENT", <subscription_id>, <event JSON as defined above>], used to send events requested by clients.
["NOTICE", <message>], used to send human-readable error messages or other things to clients.
This NIP defines no rules for how NOTICE messages should be sent or treated.EVENT messages MUST be sent only with a subscription ID related to a subscription previously initiated by the client (using the REQ message above).
Basic Event Kinds 0: set_metadata: the content is set to a stringified JSON object {name: <username>, about: <string>, picture: <url, string>} describing the user who created the event. A relay may delete past set_metadata events once it gets a new one for the same pubkey.
1: text_note: the content is set to the plaintext content of a note (anything the user wants to say). Markdown links ([]() stuff) are not plaintext.
2: recommend_server: the content is set to the URL (e.g., wss://somerelay.com) of a relay the event creator wants to recommend to its followers.
A relay may choose to treat different message kinds differently, and it may or may not choose to have a default way to handle kinds it doesn't know about.
Other Notes: Clients should not open more than one websocket to each relay. One channel can support an unlimited number of subscriptions, so clients should do that. The tags array can store a tag identifier as the first element of each subarray, plus arbitrary information afterward (always as strings). This NIP defines "p" — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and "e" — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow. The <recommended relay URL> item present on the "e" and "p" tags is an optional (could be set to "") URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.
I'd go even further and say nostr is closer to what web3 should have been: technological innovation to simplify the construction of new services.
1 billion satoshi = 10 BTC
It’s easier to just say 10 BTC. Also it makes the headline shorter
1 SATS = 0.00000001 bitcoin
Unsure why the headline was edited. Probably to get more attention as btc draws more attention than SATS
No I just think that an amount that is equal to several BTC is pointless to measure in sats.
It’s equally pointless to use sats as the units of measure for such a big amount, as it would be to say “20 million cents” instead of just “$200k”
Google told me 1 billion sats is 0.1 BTC, ChatGPT 0.01 BTC. Google was still closer :)