Last Notes
Doesn't look like it currently but we're definitely going to add FIPS and mesh support to @npub1wht…r3ec in the future. Just waiting on a few key features to land in FIPS before we start on that work.
Yeah, nah.
Don't use lists for this.
HTH
https://media.tenor.com/FVaUjRgOTZoAAAAC/anytime-youre-welcome.gif
Thank you for the explanation. It is OK, I was wondering about the concept of unskippable setup option. Isn't this approach better? "Warn the user, let them know what are the risks of suboptimal setup, but let them proceed."
You can also donate at https://ipf.dev/donate 😉
#nevent1q…29vq
Why do you have two white noises?
Your nostr profile doesn't have a link to white noise, nor does your post. Where can I get? I don't use Google or apple stores.
that was like 20-30 minutes of me working. we released new versions this morning so the community groups blew up again!
Why you never open it to see the messages? 😹
If you want to support Hisa marketplace app you can donate in the app. Your donations are peer-to-peer so we are NOT being taxed.
#nevent1q…rhue
sorry about that. i actually meant to remove that. we added it a bit ago when Will said he was turning off the damus relay but it’s still going so…
if you want to support what we’re doing at @nprofile…radp you can now donate right in the iOS and Android apps.
you can even set up an easy recurring donation with Apple Pay on iOS.
since we’re a 501(c)(3), if you’re in the US, your donation is tax deductible.
🙏
https://blossom.primal.net/933e26f1c61cfa36d6e103e533625bda99756fce9ff7db7a59b6e3b26cd4f558.png
Is this roadblocking setup necessary? https://otherstuff.shaving.kiwi/2ef8fc7b600328c32cc7441a169b5a93c6d189c70917d2adbe262a6a379f6d81.webp
@nprofile…radp ftw
https://blossom.primal.net/aeeee0a5738599bc641ee3ae1e8d1c61d1e8599f8e4d5b268c48c008fb763a04.jpg
Haven is pretty cool for local client testing
Damn, why no one uses Chronicle? 😅
gm 🌞
https://blossom.primal.net/b1fa4589104c941ff8fe9c44e445ddcf50be897c8675b383d3b986a9a0164745.png
Just make the limit for all events 4GB minus 1 byte. I'm sure relay operators paying network out fees will be accepting of that change.
I respect your opinion, and it's true, this is not Bitcoin. That wasn't my argument anyway. But I think it does matter, especially for dev expectations and consistency across the network, which is already quite confusing. It is true that there is no specific limit set anywhere in the protocol, and that 64 KB is just an informal convention, but so far, the bigger the events are, the more people with poor connectivity suffer. Also, it is the wrong technology for storing blobs. But anyway, good luck with your campaign. I think you can work around this without needing all relay implementations to converge on increasing the event size limit.
GM from Italy! 🇮🇹
A coffee ☕️ with @nprofile…g5x3 🙌🏻🧡
https://blossom.primal.net/82fbefd693538988d045d33b880dc8efd690bf1d9c859e63a34cacd2c3ca55cd.mov
https://blossom.primal.net/6017d3e3d3280d9e206f8f3f29b773765e5f1981c4515311298f7558cbeb7eba.mov
It is arbitrary, but only because it doesn't matter much. The only reason that we run our own relays for White Noise is because I monitored a bunch of the most popular relays for a few months and their uptime was dog shit.
The White Noise relays are still just relays, running normal relay software, in accordance with the spec. The only event size limit in nostr is NIP-44 payloads, which have a 4GB limit. It makes no sense to artificially limit events to a tiny size. This isn't bitcoin. We don't have to worry about nodes running on raspberry pi's running out of space.
One thing doesn't imply the other, but who cares anyways...
Block size is non-negotiable bra
For those crashing out over this... the limit on NIP-44 payloads was raised to 4GB minus 1 byte back in June. I'm not asking for a protocol change, it's already changed.
#nevent1q…wf5l
it is solved at the protocol level. in june, the limit on events for nip-44 was raised to 4GB minus 1 byte. it's just that most relay implementations & operators haven't updated their config yet.
To be honest, I don't think this is the way. Not just because it is an arbitrary value. Why 1 MB, and why not 4 MB... or more? But also because it doesn't make sense to force application logic or demands into what should be a protocol level change, if any... Pagination, chunking, all of that already works out of the box. Increasing event size limits is unnecessary churn and would never end up being satisfactory for everyone. So this would probably either make things even more inconsistent for devs who expect relays to store 1 MB+ events or, more likely, make wn need to run special relays.
#nevent1q…urzr
what if bunch relay admin decides to STICK old branch never upgrade relay or app
we can still keep our gossip without black /white or grey noise
:orange:STIR N FRY IT HARDER 🤣
Jokes aside: that sounds like a problem that should be solved at the protocol level 🪄
Nostr Hard Fork Incoming!
That the same issue for follow lists and people lists in nostr.. I will implement the sharing, but to me that doesn't solve anything since messages cannot be big. I have seen more people losing messages than losing lists, by far.
Some people indeed hit community lists that big which was why they did the sharded one. Point remains that even if you dont find it neccesary you being behind on the spec still causes issues. I don't know what armada does when it encounters a changed 13302. But it doesnt actively update its 13302 anymore so amethyst is left out on any community list updates.
But that was just for community lists, right? Are people having more than 64KB of community headers already? That sounds crazy. What do you do in messages that are bigger than 64kb?
Try going around and opening a PR for each of the major ones. It lowers the bar for saying yes so might get you where you want to be quicker.
The concord spec changed a month ago to deal with those limitations. So the communities you join are now sharded on armada and vector. At the time you did not want to update amethyst. Now that means pretty frequently people wonder why their communities from Armada do not sync correctly. And we have to explain its because Amethyst never updated itself to the newer spec.
So amethyst not only doesn't get the proper channel sync, it also is subject to the limitation issues that change solved to begin with.
Once you implement the sharding kínd 33302 instead of sticking to 13302 you are in line with the spec again so people dont miss channels and dont risk issues with their community list.
https://github.com/concord-protocol/concord/commit/759448ab637abd2ccabe1026b8f8ad80569cfea5
Because of what? Event size? We don't operate relays. I am confused..
I know concord ran into the same issue and switched to a sharded system to bypass the limit.
@nprofile…vhl6 its been a month now are you finally going to bring amethyst in line with that now? We keep having to tell people not to use amethyst for concord because of this. Would be nice if it was actually compatible again.
no - a 200 person group has a welcome message of about 300kb. the MLS welcome object itself is only about 100kb but then we nip-44 encrypt and base64 it, so it gets bigger.
I just think 1MB+ is a better size limit is all.
that over 1KB per user. I'm curious what causes this number to be that large? encryption overhead?
it's an easy fix too. 🤷♂️
my relay implementation Wok has higher default limits. Khatru, Haven, and others also default higher than 64kb now. It's basically just a historic holdover.
total event size. this only for welcome messages that invite people into the group (which are gift-wraps - kind 1059). most group messages are kind:445 and are tiny.
Relay op here, are we talking 1mb per message or is this the projected size of the events forming the group?
disagree. nostr relays work great once you get past the broken ones.
