*cloned not closed. Autocorrect
Still haven't gotten an answer with certainty. Can't tell if the wallet keys derived from nostr keys are closed for repeat use or re-generated across a range of possible derivations.
More ideas seeking feedback
Sketchy Idea Proposal 450 - in-wallet RNG guidance
Suggested flow - check replies for a shitty HTML demo or updated versions
https://svgshare.com/i/18RK.svg
Wallets should guide users through as much understanding of random number generation as they could ever possibly want, like other elements of wallet security devs try to be very informative about.
Vanity key generation should include warnings of the security risks associated with it; and so should instantaneous key generation in general, instead offering the option to generate a more securely randomized key by hand with coin flips or dice rolls.
It should not only be explained to users that their seed is important to keep from being lost or stolen, but also that a wallet's coldness can be enhanced by air-gapping and ensuring proper randomization of seeds.
Guidance should be available to users on the aforementioned process of generating keys by hand. This guidance should include both built-in tools and outside resources, and ideally, an intelligent user should even be able to verify the cryptographic functions of electronic systems by hand, using suggested guidance.
-------
Related: Sketchy Idea Proposal 451 - guided brainwallet setup
Going a step beyond verifying the functionality of electronics, it would be great to help the user perform cryptographic functions with less involvement from electronics in general. This would be particularly useful for the sake of "brainwallets." Guidance could be available on how to do checksums and derive wallet addresses using pen and paper; or, if that wouldn't be possible, perhaps using a calculator, as it should be easy enough to wipe its memory; or, if a mere calculator still isn't enough, perhaps something like a PlayStation 1 or a Nintendo 64, which hopefully still shouldn't have too much spyware compared to a typical modern laptop or phone, while being much closer in power than a calculator.
Funny how we all seem to be struggling to understand what we're reading.
Maybe the anti zaps can just take back tips that haven't yet been transferred again?
Is this NIP-570 using cryptographic wizardry I thought only existed in legends to avoid address reuse for on chain UTXO nostr tips? 🤯
Wait, does this NIP-570 already avoid address reuse? I may have misunderstood at first
woo, on-chain zaps and antizaps working on testnet.
https://mempool.space/testnet4/tx/6d8d2c26fb6f68097c7bbca6843d3ef475368d6211c837632446bc4a0f3f162a
Draft NIP 570
https://gist.github.com/melvincarvalho/15f767fee8ed3e14197b322235e9fe8d
Looks like we're both thinking about this stuff at the same time. You may want to consider avoiding address reuse in NIP-570 like in my suggestions 🤙
Sketchy Idea Proposal #00: Legacy nevents
Let's call the pre-existing protocol's nevents "legacy nevents" because they'll be sticking around - there's no way all devs, relay operators, etc will agree to migrate to SIP-01
-------
Sketchy Idea Proposal #01: New nevents
Let's have new nevents which are just legacy nevents reformatted in accordance with the following criteria:
1. No English or other natural language in the code for nevents anymore; be more efficient, computers don't need extra binary bits for all the unicode characters to turn field IDs into words. Metadata fields, for example, can be referenced with more efficient binary than repeating their names every time they're used in the backend. The frontend doesn't need the names of metadata fields repeated in the backend for the user to see them. Fix all that stuff for each type of legacy nevent reformatted to a new one.
2. Make sure a language field is included in the metadata for kind 1 nevents.
3. Make sure a version letter is included in the metadata for kind 1 nevents. This is Latin-alphabet-centric but is a convenient and efficient way to provide for tracking up to 25 edits.
-------
Seeking feedback
All zaps forwarded to fiatjaf as a token of respect
#nostr
Some more, but this time it's just concepts I've already talked about before.
SIP-700: seed word generator
With no private-key functionality, the "seedgen" makes seed word sets to match user-defined public key criteria, allowing:
* creation of vanity npubs
* creation of vanity wallet addresses for fixed-address cryptocurrencies such as ethereum classic
* mixing/matching e.g. vanity characters at beginning of npub and at end of etc address
SIP-701: keygen
Takes seed word inputs and generates keypairs for nostr and wallets. Can try to generate seed-matching vanity wallet addresses for rotating-address cryptocurrencies such as bitcoin, monero, or doggie coin.
SIP-702: tip address bot
Collaborates with keygen, nevent signer, and relay to respond with rotating wallet addresses to any message containing 2 deltas (ΔΔ) followed by a space followed by a recognized cryptocurrency name in unicode. User should be offered the option to modify the list of cryptocurrencies by defining a name in unicode along with a wallet address derivation path. Tip address bots can be made compatible with legacy relays and/or new relays as defined in SIP-703. A new method of tipping can use these bots, where the tip recipient sets their tip address to the pubkey for the tip-bot, and a tip-sender's client automatically messages the tip bot "ΔΔ dogecoin" to get a doggie coin wallet address, for example. The wallet bot can use a list of wallet addresses fed to it by a user's keygen, or can have its own keygen, with either the same 12 word seed or a different seed (the user still needs to keep safe).
SIP-703: new relay
Just sends and receives data in a given format over given input and output points. Has its own npub and index of other relays.
An example of a relay would be a command-line tool that accepts binary data at its IP address and can send data via the command line to the known npubs or IP addresses of other relays at other known IP addresses.
Another example of a relay would be a Discord chat bot that can receive unicode text via Discord messages and can send unicode text to the npubs or Discord accounts of other relays at other known Discord accounts.
It just so happens that the content being sent over relays can be nevents. These SIP-703 relays require configuration with additional components such as nevent libraries (SIP-704) and nevent signers (NIP-46 and others) in order to be useful for #nostr
another bounty I'm thinking of setting a small amount of Monero on if possible (seeking feedback first) -
sketchy idea proposal 100: a natural-language-agnostic programming language
explain a clear position on HolyC, respecting the talent of Terry Davis while describing why it isn't the perfect compiled programming language in your opinion. (this is the opposite of SIP-101 and both bounties can't be claimed by the same entity)
review the McDonald's interviews, and for bonus points, any other content of Terry's you find interesting.
set aside a few minutes to find or create a different programming language, with all the strengths you see in HolyC and fewer or none of the weaknesses real quick if you don't mind.
this programming language can be found in existence as-is to collect the bounty if there's one out there that meets the criteria (I'm not a coder and haven't been able to find clear answers); if no such programming language exists, it can be created from scratch, or forked from another compiled low-level language, preferably HolyC, Assembly, or C.
make sure the new programming language has a simple "hello world" program that stands in at least some way as an intuitive showcase of why this programming language is an appealing one to use. I recommend working out this part of the design and agreeing on it beforehand to be sure there's no disagreement of whether this condition is met later in the process of collecting the bounty.
make sure the new programming language is agnostic to the natural languages of humankind, which can be done in 1 of 3 ways:
Option 1: The programming language has no out-of-the-box functionality which is based on any particular language's words, instead everything is based on arbitrary symbols and such; when developers use strings or otherwise add natural-language-based functionality, the human words must be indexed in a consistent format where the index can always be consulted for translation purposes
Option 2: the person mainly credited with creating the programming language seems fluent in a natural language other than English; and this person uses this other language instead of English in designing the language; and most importantly, this person carefully indexes every example of any part of the programming language which uses human words, with the index denoting the words used in the terms of the programming language, and what natural language each word is from; and each of these natural-language-based terms is numbered, and this whole programming language is fictional because compiler does not actually recognize the natural-language-based terms, it only recognizes the numbers; as a result, there must either be an automated method of replacing the terms with their numbers, or a manual find-and-replace being done by developers to convert code to the real programming language before compiling; also, just like in option 1, the programming language requires developers to index their strings in a consistent format which can be consulted by translators; so ultimately this is the exact same thing as option 1 if you think about it
Option 3: the exact same as the previous option, except with different compilers for each language instead of the "real" underlying language using a numbered index (why tho?)
In options 2 and 3, the language must have a translated English version. The goal in options 2 and 3 is to have localized versions of the language itself, so it helps to have at least 2 versions, with English being one and the original being a different one.
finally, the real hard parts of collecting this bounty:
1. make it believable that you have met all these conditions, to a paranoid but reasonable layman (non-coder)
AND 2. show at least 2 other bounties or interesting projects which have been completed with extensive use of this programming language. Any bounty is valid if it shows extensive use of the language; other projects will be judged more subjectively. The language creator's involvement in these projects is completely optional (the language itself must be involved).
as with the previous 2 posts, forwarding zaps to some good npubs because I don't use lightning much
another one I'm thinking of setting a bounty on
sketchy idea proposal 101
explain a clear position on HolyC, describing why it is the perfect compiled programming language in your opinion.
also, create a new compiler for HolyC real quick if you don't mind.
one of a few bounties I'm thinking of setting on monero.social if they'll allow my nostrichly intrusion
sketchy idea proposal 102: JavaScript learning resource
put JavaScript documentation in the NIP-54 wikis (open to other wiki options), with a particular focus on cybersecurity and detailed coverage of functionality and usage, to serve as a resource for devs and security analysts
format the wiki entries with consideration for other information people will want to add, such as reports of issues certain functionality can have in certain browsers, etc. (maybe make pages or wiki-links for related categories of information as appropriate)
make a discussion platform where specific narrowed-down subsets of JavaScript functionality can be stipulated and discussed as complete packages; for example, a dev can list the documentation articles for everything they used in their project and explain why they think the set of components they used is safe for their use case; and if other devs and analysts agree, they can try to use the same components in their projects; and users (even a layman) can see differences and similarities in how different webpages and developers handle JavaScript
make sure there these lists of JavaScript functionalities are actually recognized, based on links to relevant documentation, and explorable in a systemic way, not just text - have stuff like a "click here to see other projects that use this" button (or whatever else instead, just anything working)
do all of this on nostr and make sure it's accessible via Tor
the project will never be complete in the sense of having all possible information entered into it, so for it to be considered complete, get at least 3 people from the nostr dev list actively using the project to discuss and hone their JavaScript
nostr dev list -
nostr:naddr1qvzqqqrcvgpzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ceqythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qq9xummnw3ez6er9wees4uz2tv
https://wikifreedia.xyz/nostr-devs/npub1m4ny6hjqzepn4rxknuq94c2gpqzr29ufkkw7ttcxyak7v43n6vvsajc2jl
forwarding zaps to some good npubs because I don't really use lightning much. posting this here with a few other ideas to come, before trying monero.social, because I'm not a real dev and I need feedback from the people who might make use of my ideas
Definitely not signing up for GitHub so if you happen to have access on there, feel free to copy and paste anything you want to the GitHub Issues section too
Scratch that, I actually think I might end up setting some monero bounties of my own so I signed up for monero.social myself
1. No, not better or more productive
2. You could delete events while keeping your nsec backed up so you're always free to log in again
Not Will tho, he gets a free pass to be regarded for inventing npubs.
Lol, "regarded"
A nostr account is never truly deleted, only your access to signing signatures from the same key. I don't suggest burning your key or other such permanent measures. It would be better for everyone if your voice remains in the pool of voices