Gotcha, I was thinking along the same lines and we discussed this in one of our design calls. I heard an argument against listing maintainers/contributors and that's leveraging natural abstractions: Fabricating a pencil involves a huge amount of people and they're not all listed in a single place, that's what the price system is for. You pay a certain amount for the pencil and the company internally distributes payments.
If a project requires this level of detail they probably should be using something like nostrocket. Thoughts on this nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p ?
And again, I don't think kind 30063 releases should be immutable (file metadata definitely should). In all honesty, who do you think will be issuing trust attestations to an event pointing to binaries in 7 different architectures/platforms/OSs? Who would be vouching for all of those binaries at the same time?
And by the way: we already have a way of including attribution. When I first floated this idea a few months ago I believe it was Pablo's recommendation to use the combination of `p` and `zap` tags to achieve it. NIP-57 appendix G goes over this mechanism.
Gotcha, I was thinking along the same lines and we discussed this in one of our design calls. I heard an argument against listing maintainers/contributors and that's leveraging natural abstractions: Fabricating a pencil involves a huge amount of people and they're not all listed in a single place, that's what the price system is for. You pay a certain amount for the pencil and the company internally distributes payments.
If a project requires this level of detail they probably should be using something like nostrocket. Thoughts on this nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p ?
And again, I don't think kind 30063 releases should be immutable (file metadata definitely should). In all honesty, who do you think will be issuing trust attestations to an event pointing to binaries in 7 different architectures/platforms/OSs? Who would be vouching for all of those binaries at the same time?
I don't think there's a way to verify a package other than trusting the builder/signer. That's what reproducible builds are for.
Artifact hashes: yes, NIP-94
PGP: we're adding it to kind 0s! Currently building a tool developers will use with the ability to attach their PGP keys or certs. See
yes these are all youtube music clients
I like Harmony Music, it's on zap.store 🤙
will check out and index ViMusic!
Super cool. For binaries, I thought about aligning with the work that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has been doing with nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcsrhspy. One or more 'App Profile' events could reference the repo announcement and share WoT heuristics.
A binary 'release' event linked to one or more 'App Profile' event then is a list of nip94 events referring to the each file in the release.
Trust attestations could be made against the repository, app profile, release, or authors of these events. You could have services like nostr:nprofile1qqsw3znfr6vdnxrujezjrhlkqqjlvpcqx79ys7gcph9mkjjsy7zsgygwr32sk's binary watch signing trust attestations for releases that support reproducable builds.
It makes a lot of sense to me to use 'App Profile' and not only because it aligns were the zap.store. A repository may contain one or more 'app profiles'. Maybe its a mono repo or has different releases for say desktop and andriod.
I've thought for a long time that DVM would be great to do CI/CD instead or relying on git hooks.
I'm keen to hear your ideas. What thoughts are bubbling away?
Super cool. For binaries, I thought about aligning with the work that nostr:nprofile1qqs8y6s7ycwvv36xwn5zsh3e2xemkyumaxnh85dv7jwus6xmscdpcygpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8thwden5te0dehhxarj9ekh2arfdeuhwctvd3jhgtnrdakj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qxvpy4 has been doing with nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcsrhspy. One or more 'App Profile' events could reference the repo announcement and share WoT heuristics.
A binary 'release' event linked to one or more 'App Profile' event then is a list of nip94 events referring to the each file in the release.
Trust attestations could be made against the repository, app profile, release, or authors of these events. You could have services like nostr:nprofile1qqsw3znfr6vdnxrujezjrhlkqqjlvpcqx79ys7gcph9mkjjsy7zsgygwr32sk's binary watch signing trust attestations for releases that support reproducable builds.
It makes a lot of sense to me to use 'App Profile' and not only because it aligns were the zap.store. A repository may contain one or more 'app profiles'. Maybe its a mono repo or has different releases for say desktop and andriod.
I've thought for a long time that DVM would be great to do CI/CD instead or relying on git hooks.
I'm keen to hear your ideas. What thoughts are bubbling away?
This is great, would love to see us collaborating here.
Here's a basic class diagram of what's being used in zap.store in production:
Applications ("App profiles") are the proposed NIP-82 (kind 32267), see here: https://github.com/nostr-protocol/nips/pull/1336
Releases are already in NIP-51 (kind 30063) and point to one or more NIP-94 (kind 1063) file metadata events.
I would probably start making attempts using OpenVoice2 through Pinokio. The problem here would be either having it live read the text, or process the entire text at a single time. Might have to do something clever to get that setup to work.
pinokio.computer
https://pinokio.computer/item?uri=https://github.com/cocktailpeanutlabs/openvoice2
https://github.com/myshell-ai/OpenVoice/blob/main/docs/USAGE.md
Thanks Guy, will have a look
Morning big birds
What's a good AI service for turning an ebook into an audio book? Paid in sats preferably
RFC: Cashu zaps NIP
https://wikifreedia.xyz/cashu-zap-nip/f7z.io
Proposal to make cashu zaps where the payment itself is the zap (instead of waiting for a zap receipt from the zapper)
The sender locks a zap to the recipient's pubkey, optionally sending to a mint the user has recommended before (kind:38000).
Cashu is a bearer token so the receipt IS the money and the money IS the receipt.
nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg
wikifreedia replacing the NIPs repo? 🤙
Hey sorry about that. Next release in the following days should fix it, and if not the error messages will be more clear
Happy to see you're getting your hands dirty. NIPs emerge from code!
Time to write harmful code 😉
I bet they could throw more money at lawyers to fix that problem and they're choosing not to. Profit over morality.
They should have a public statement they point to when they can't give detailed explanations, like the source of the law. Or is that secret too?
Interesting post.
Why do KYC services cannot give explanations when freezing accounts? Specifically this guy was in Brazil.
Is this the actual law or some kind of secret?
I have had issues like this with other services in different jurisdictions. All KYC services can go fuck themselves.
Pushstr? 🤔
I am considering moving Amethyst's Push Notification features to a separate app. If that "decentralization" becomes a thing on Nostr, multiple Nostr clients can use just one Push Notification App that keeps downloading of all events citing the user and forwarding to each local client, including the local relay.
When a notification arrives, the Push App pings your preferred Signer app to decrypt it and shows it on the system tray. If you click on the notification, it opens the Nostr event in your preferred Nostr Client for that event.
The good part is that multiple "Push" apps can exist with different ways to address the need for push notifications (using Google Services, NFTY, etc)
Then we would have broken down into Amber (Signer), Citrine (Local Relay), Amethyst (and other clients) and the Push App.
What do you think? nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usjfpck
interesting!
Thanks, appreciate it! I could use some of your help to protect our relay and API services
Thanks!
lol thank you for that
One of my main goals with zap.store is to help raise the quality bar of open source software.
Most FOSS is basically driven by programmers' passion – but on average programmers suck at UX.
We need better incentives for more professionals other than programmers (designers, product people, psychologists) to join open source projects and turn them into real competition to traditional high-quality closed-source applications.
I appreciate and support you guys, and understand the situation, but I would've appreciated an earlier heads up on you turning off Lightning addresses
nostr:npub1mutnyacc9uc4t5mmxvpprwsauj5p2qxq95v4a9j0jxl8wnkfvuyque23vg I have franzap@mutiny.plus on my nostr profile and unable to be zapped.
Zaps apparently go to the federation (I had freedom one which is still down?), what is the status with that, should I change to another one? Which one? I don't see a good obvious choice and don't want to choose a guardian with an xyz domain.
I also closed my channels to the previous LSP and reopened one (with zero inbound this time) and every time I attempt to send to my other wallet I get a failure. Tried 3 times yesterday and today.
What should I do to make this work again? I mean, other than changing my LNURL address
nostr:npub1u8lnhlw5usp3t9vmpz60ejpyt649z33hu82wc2hpv6m5xdqmuxhs46turz
Ok last attempted worked. I have inbound now. Still unzappable