Off-topic: notice how using kind:1 to announce other kinds end up hurting the other event by splitting comments in two places 🧐
If we forbid dots on nip05 usernames, we enable @username.subdomain.domain.tld
All nostr users have a native bitcoin address.
Bitcoin pubkeys and nostr pubkeys are the same address with a different prefix. You can send btc to your npub on-chain and your nsec can unlock it.
nostr:nprofile1qqsdulkdrc5hdf4dktl6taxmsxnasykghdnf32sqmnc7w6km2hhav3gppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytfsxyhxymmvwshx7cnnv4e8vetj9uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qmml2f has even explored the idea of on-chain zaps
https://gist.github.com/melvincarvalho/15f767fee8ed3e14197b322235e9fe8d
Negative Zaps is like casting a "macumba" on someone?
Its great that there are clients that compress media before uploading. But one of the good things of NIP-96 is that it makes it easy for clients to offer uploads by not requiring any client-side media transformation logic.
An amend to NIP-96 could add a query string like `?ref=x` when downloading to only respond succesfully if server has a file with `x` value equal to the hash used to request the file.
For uploads, NIP-96 already has "no_transform" field, which would make `ox` equal to `x`.
Reporting: still building the web client. This thing takes huge time to develop properly. I mean, there are clients that are here for years and don't even have outbox model implemented yet, which is basic. Atleast I got this done. I got a great app name too lol this is the most important step.
I'm not giving details yet cause I am avoiding saying "X feature currently is not done right in other nostr apps and I have a solution to that" while implementation isn't finished. I have a bunch of new ideas to work on.
Believe mah words!
nostr:note1qg4ql34n08p0n3kjqyac8kt8az6u423603ayed2fk55satnjdk9qrl5gxtRight, now make all this simultaneously for two feeds and merge them into one ⚰️
Great, I see you're building a web client too! Maybe If one of us manage to dethrone primal.net we can make a petition to change the nostr mascot from an ostrich to Blanka 
For all believers like nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn nostr:npub13sx6fp3pxq5rl70x0kyfmunyzaa9pzt5utltjm0p8xqyafndv95q3saapa nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz nostr:npub1l3cgtsurhfchg4cyhhqudm70074sr96srhje330xc5m6czej5n9s9q6vs2 now it's your time to dance in the face of nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft.
Performers from Brazil called Carreta Furação
https://www.tiktok.com/@memestrenzinhos/video/7317363637516012805
Day 1 of coding the nostr client...
Once a nostr elite told me "It might be harder than you think".
It made me think of Naruto anime where there are some elite characters ranked as geniuses, naturally talented, while some plebs like Naruto himself and Rock Lee never gave up trying to improve themselves by relying on hard working.
.jpg){kind=avatar}
Time to apply all the theory learned at the University of NIPs. I completed the course with an average grade of 5.7 rounded to 6.
Not necessarily gonna pursue low-data usage at the cost of poor ux. It is more like taking advantage of knowing well how nostr works to not ship code that carelessly connect to more relays and asks more events than needed.
I think NIP-27 and NIP-96 were very important to the protocol, although the latter was a real pain to get everybody on the same page and merge. It was also important to be there and nag about NIP-42 till nostr:nprofile1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uqzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vahj2kfz came up with the "CLOSED" message as a solution to most problems. I like unmerged inline metadata NIP that I think nostr:nprofile1qyghwumn8ghj7mn0wd68ytnhd9hx2tcppemhxue69uhkummn9ekx7mp0qythwumn8ghj7anfw3hhytnwdaehgu339e3k7mf0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qpqgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqss2dqr is still using and I will too but I guess nobody else is for now.
Some things had to change on the protocol before being too late to change, even though I wasn't implementing anything at the time.
I see your point though.
Agree. When writing a NIP I think of implementation though its hard to spare enough time to actually implement it. Until now the way I wanted to help was just writing NIPs so others that had clients/relays would implement them instead of me.
I did write some relay and client code though I need to inject some caffeine and complete the damn things.
I was thinking of lazy loading feed with manual refresh (also lazy loading threads instead of loading all thread notes at once like most clients do). No new live events until user manually refreshes.
I'm thinking of starting development on a new nostr web client to implement my ideas that always get bashed on the NIPs repo by the nostr gods.
If you are seeing this in the middle of a million notes on a global feed and is interested in an web client that won't suck all your mobile internet plan in a day, follow me for news.. and for rants on nostr NIPs repo scene =]~.
PS: any huebr there?