"On the right track" for 10 years. IPFS is a joke, it cannot ever possibly work.
So here is the solution for writing apps "on Nostr": https://github.com/nostr-protocol/nips/blob/master/78.md
And also if you see yourself wanting to save preferecens, settings, anything that you know other apps won't care about. That's probably the way to go. The NIP can still be improved.
So here is the solution for writing apps "on Nostr": https://github.com/nostr-protocol/nips/blob/master/78.md
Ganhaste, mas não te zaparei pois meu cliente não me permite que eu zape.
Ah, se eu zapasse como outrora zapara! Ah, se tu zapasses como outrora zaparas! Ah, se ele zapasse como outrora zapara! Ah, se nós zapássemos como outrora zapávamos! Ah, se vós zapásseis como outro zapáreis! Ah, se eles zapassem como outrora zaparam!
Eu zaparia, tu zaparias, ele zaparia! Nós zaparíamos, vós zaparíeis, eles zapariam!
Quando eu zapar tu zaparás! Quando tu zapares ele zapará! Quando ele zapar nós zaparemos! Quando nós zaparmos vós zapareis! Quando vós zapardes eles zaparão! Portanto que eu zape, que tu zapes, que ele zape! Que nós zapemos, que vós zapeis, que eles zapem!
Eu zaparei, tu zaparás, ele zapará, nós zaparemos, vós zapareis, eles zaparão.
Eu zapei, tu zapaste, ele zapou, nós zapamos, vós zapastes, eles zaparam.
That was never a design principle.
Lightning is such a broken system.
You need the &xs= parameter pointing to the URL of the torrent file otherwise it will only work if someone is seeding (because magnets themselves do not hold the torrent metadata, only a hash of the metadata, and the metadata is required to verify the downloaded pieces, so it must be fetched first from either peers or from the &xs= URL).
The nicest thing about Nostros is the refusal to publish to Google Play.
#[3]
I think the way this bounty is stated is put is not the ideal. I think most people will read this and think we need a big website that is just like GitHub but using Nostr somehow. I think that is not what we should see (and hopefully that's not what #[1] wants either).
What I would want to see are multiple apps that can interoperate and are able to perform separate functions:
- browse code
- comment on code (referenced by a commit)
- create issues and comment on issues
- send patches
- comment on patches
And how these should be done? I am not sure, but here's what I have in mind:
- most of the comment things should probably be kind:1 events, I don't know, with some extra tags (so they could be interacted with from the normal "social" Nostr clients? or not?)
- code should probably be hosted by standalone dedicated git servers -- and there could be centralized providers offering these services but they should interoperate seamlessly between themselves and with standalone personal servers
- sending patches should probably be done using something like this approach by #[0]: http://git.jb55.com/git-nostr-tools/file/README.txt.html
#[2] has opened a discussion on this topic on the NIPs repository that could possibly be used to coordinate the efforts: https://github.com/nostr-protocol/nips/pull/223
I think we could have multiple different smallish webapps, native apps and specially command-line tools that implement one or multiple of the separate functions described above, and with that we can achieve a much better result both in terms of quality and of decentralization than if someone or some big team decides to tackle the entire cake and come up with some centralizing architecture on their own.
It's a network-effect argument. Centralization is just the means that is generally achieved.
I also think they are evil.
I'm not seeing impacts or results either way. But I dislike the feel of bounties. They are like hiring someone without screening them first and without being able to tell them what to do.
Developer agency is all that matters, but the central agency must still decide who gets the bounties and who doesn't.
I have never heard that phrase inside ZBD, sir.
An strfry plugin most people should be applying: https://gitlab.com/soapbox-pub/strfry-policies/-/blob/develop/hellthread-policy.ts
I think I am not going to put out any bounties anymore, that is not working. If you have a project idea in your head -- or more than one project idea. Talk to me on https://t.me/fiatjaf (yes, yes, I know) and I can create an instant bounty for it pre-committed to you if I think it is worth it. Does that sound sensible?
Also if you think someone deserves a bounty but hasn't gotten any please let me know.
I think I am not going to put out any bounties anymore, that is not working. If you have a project idea in your head -- or more than one project idea. Talk to me on https://t.me/fiatjaf (yes, yes, I know) and I can create an instant bounty for it pre-committed to you if I think it is worth it. Does that sound sensible?
I need help implementing it. It exists at https://github.com/nbd-wtf/nostr-tools/blob/nip41/nip41.ts but I need someone else to implement it elsewhere so we can compare things and clarify the spec. Then we can start using it.
The beauty of NIP-41 is that it doesn't need any existing client to support it. You just need one thin micro app that people visit every now and then to update their contact lists after invalidation events and then that gets pulled in by other clients.
#[0]
Forwarding is complicated, #[4] proposal I think explains it best.
Root key with delegation and fiatjaf's proposal look good. However, to use them still requires transferring to a new key.
Using out-of-bound means, like NIP-05, to be the source of information about the new key, combined with a means to revoke a key looks like it could be an option.
I need help implementing it. It exists at https://github.com/nbd-wtf/nostr-tools/blob/nip41/nip41.ts but I need someone else to implement it elsewhere so we can compare things and clarify the spec. Then we can start using it.