Byzantine 
Spooky 
nostr:note1tuj35xfk5c4yhfalct38ppyyax0uvlwyddsj64qrjj7dv076t2us9hd5jp
I always have a more tender heart toward the Germanic words in
English.
Things that we mostly can't fix, but that maybe could have been done better if they were here from the beginning -- or something like that.
- The `NOTICE` message would have been better if it had structure like `OK` messages have. That would have allowed a more direct communication between relays and users, instead of relays being inside a client black box.
- Choosing secp256k1 felt cool and maybe it still feels cool because it is the Bitcoin curve, but since many people have pointed out that other curves and algorithms are much faster maybe picking those would have been better.
- Writing a spec for direct messages and implementing them was bad. In my defense, it was an attempt to [please the public](https://t.me/nostr_protocol/307), but still I should have not have done that, or thought more about it before doing it.
- Thinking that kind 1 should be used for all the things "text" just restricted the ability of clients to do different interfaces. If we had different kinds for replies, quotes, comments and "root" posts from the beginning that would have been better.
- For a long time I didn't realize Nostr wasn't useful just for "social networking" things. I wonder what else could have been better designed in the relay-client interface if the needs of non-social-networking apps were kept in mind.
- The querying system is sometimes too generic, it could have been better if it was more restrictive, but more complete. For example: allowing generic querying over tags is weird, can lead to O(n²) issues in some cases and relays are left to fend for themselves -- on the other hand we can't query for the absence of some tags. But I don't know how any of these things could have been better even today, so maybe it wasn't so bad.
- Making the events be JSON: sometimes I think this was a bad idea and a binary format would have been better, but most of the times I think Nostr wouldn't have become any popular at all if this was the case -- also binary is slower than JSON in JavaScript, so I guess this wasn't a completely bad choice. Perhaps if something like [NSON](https://github.com/nostr-protocol/nips/pull/515) had been adopted from the start, though, that would have been better for everybody.
When I decided to write this I had one item in mind, but when I started I forgot what that was. I'll add it here back when I remember.
Did you ever remember that one thing?
Get rejected and was grumpy about getting it in the first place. 🤦♂️
Since you’re asking, I would say your vibe is a little off. Like when you asked fiatjaf about the soul on your podcast. Thinking out loud here… maybe would say you treat heavy things as trite.
Hmmm, there’s basically bracketing characters available: (), [], {}, <>
And then a handful of others: :, ;, &, @, #, %, ^, *, +, =, |, ~, •
nostr:note1jndql5z4z95gzyfcjjcsxywzlqx0q3l5p0fpldq6v35kv20xk3wqvp32zc
🍿
Mt. Celery
#foodstr #grownostr 
I think could work. But I think nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr is going more for a pure chronological feed and therefore wanting to treat replies more like standalone feed items.
I think indenting them might go against this philosophy.
New version is definitely an improvement. 🫡
Haha I’m not going to do that 😂
Applied for my first credit card ever today. Devastating.
I guess what I would want from a reply would be that it is clearly shows dependency on the parent note.
In the current view, the parent note is displayed the way I would expect if I was quoting it, not replying to it.
In the proposed view, the parent note is removed, making the reply a sad orphan.
Is this an improvement?
Old: 
New: 
Changes are only on the alpha version for now: https://next.nostrudel.ninja
So, I do think this needs improvement, but I’m curious about your philosophy.
Do you have an opinion on grouping replies under their parent versus treating replies as standalone objects?
14000 kind 1 notes is about 7MB in nostrdb. Heaviest is contact lists. 4000 lists are about 70mb [1]. These are stored in a compact binary format so they are pretty space efficient, but it’s amazing how many notes there are floating around. I hit 14000 text notes after a few minutes of use.
Working on #nostrdb pruning logic so that #damus will use less space. We probably don’t need to store everything, so I am working on making sure only the important stuff sticks around the longest (profiles, etc). Storing text notes is nice for when we add note searching.
nostr:npub13v47pg9dxjq96an8jfev9znhm0k7ntwtlh9y335paj9kyjsjpznqzzl3l8 has been working on more aggressive image cache pruning. Images make up most of the storage space, so we’re making sure damus as space efficient as possible for the next release.
It’s nice to be back hacking on damus 🤗 whats everyone working on today?
You know it’s serious when will starts .txt posting. 👀
But isn’t the rule against markdown in the nip-01 spec for good reason?
I don’t think clients should be modifying events, but a reasonable option would be to ignore them.
