Thread

Please do, writing specs only goes so far, it's much better to back them up with real world use cases.

What about a client that does not guzzle your battery because the feeds refresh rate is constant & has no option for control?

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.

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.

How many of your NIPs have been adopted and merged? I know Vitor has picked up a few, but most NIPs emerge out of developers solving their own problems, not other people offering solutions. I began my nostr journey by writing my own protocol. Fiatjaf dismissed me as an academic, until I gave up on my ivory tower and started writing real software - on nostr, because I realized I couldn't build a protocol on my own. I think he was right to do so.

A low-data client with a good ux would be awesome. Gossip does some of this, but it's desktop

it should be possible for egui to be built to run on mobiles too, if the UI has been changed to fit the dimensions... i was working with an IMGUI library called Gio back in 2018 that you could do that with (golang of course)

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.

Based

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.

It might be harder than you think

the lack of negation operators in the filter spec of nip-01 makes low bandwidth hard to do without a sophisticated relay side filter filter

like, just to elaborate a bit more, i've thought about the idea of a relay that if it can find your mute list, automatically excludes them, it would cost more processing so it's definitely something for a paid relay

Who are you? The real arthurfranca would never use Nostr or write anything besides new NIPs.

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.

Waku Waku!

who are these dudes?

Performers from Brazil called Carreta Furação https://www.tiktok.com/@memestrenzinhos/video/7317363637516012805

Happy to see you're getting your hands dirty. NIPs emerge from code!

huehuebr here, let me know if I can help 👊

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