It's funny how many gov-fighting bitcoiners are against woman, and not government, deciding what to do with their own body. It's almost as if they don't actually believe in freedom.
Periodic reminder to keep a max of 3 relays in your outbox and inbox relay lists.
There are too many people with 20+ relays in there. You are forcing all of your followers to connect to 20+ relays to see your posts (outbox) or 20 + relays to see your replies, likes, zaps to your posts (inbox). Zaps to you are massive.
And I am willing to bet many relays in your list don't even receive your posts. Which is even more wasteful for your followers.
You are breaking Alby:
nostr:nevent1qqs8lwes70xltmqnz7qg7wq5uew5e8ny0s9zh3x9fz44atyw5ekrdqsppemhxue69uhkummn9ekx7mp0qgsrxra3gv0lnkxz2pcxh0xuq9k4f9dr7azwq3aypqtnay4w0mjzmtqrqsqqqqqp3w9nel
If you have 20+ relays, and clients don't connect to 20+ relays to send, the clients that are trying to see things need to connect to all 20 relays to get everything from that user.
One side must always connect to 20 or a LOT of things will be missing.
Which is extremely DUMB. Just reduce the amount of relays.
Sure, but meanwhile, people need to take responsibility for their lists. Most don't. They just adds a bunch to shit and expect things to magically work.
Most likely apps will just crop to the first 3 relays and if the first 3 are crap no one will see people's posts.
It's up to users to choose where to store their posts. If they choose crap, they get crap out of the system.
No, we can't. Either the sender of events MUST connect to 20 relays so that all 20 have the same info and receivers then don't need to connect to all 20 OR The sender just sends to ONE relay and receivers must connect to all 20 to get all events.
There is no "smart" way around this.
That's why keeping the list small is EXTREMELY important.
The relay lists should be published to as many relays as possible. That's why they need to be small. These records are the main points to get people to find you and your posts. So, they should be everywhere.
It means that your old follow list was not posted to the relays you choose. You can add them back and try to repost it there. If it doesn't work, the relays you selected are not accepting your follow list. It might be too big for them.
Maybe, but all 4 do the same and want small lists. Every body else uses kind 3 relay lists (The general section on Amethyst). You can keep large general section lists, and smaller outbox lists.
Only the outbox lists must be everywhere.
The outbox list is like a DNS, it points to where (which relays) your metadata, mutelists, follows ect are. So, you don't need these other events everywhere. They can all be hosted by the user's home relay.
No, the 3 relays are the relays you have chosen to store your posts and to receive your notifications from other users. They can be anything you want them to be. Every client should connect directly to them to download your posts.
The receiver will pick one of them to download posts from, so make sure ALL of your posts are there in ALL of them at ALL times. Meaning... Pick good relays.
This is for the outbox relays only. Other relay lists might want more or less depending on each use case.
I have 3 in my inbox outbox list: nos.lol, vitor.nostr1.com and Nostr.wine . I don't know what primal is looking at. Maybe they are just summing all relays from all the multiple lists into one.
Yep, the relays clients use to send things come from other lists as well. The inbox and outbox lists and just for your follows to know where you post as. Not for you to use in your apps.
Public OutBox and Public Inbox are for your followers. If they can't use those relays, there is no point on keeping them there.
You can use the Private Home, Local Relays or the general list to keep things that only you can access.
That's an issue we don't have a good solution for. But usually relays have a terms and conditions and privacy policy on what they receive and keep. You should ask the relays you are using for that documentation.
If you are paying, they keep your notes.
But other than that, the relays icons below each post author refer to which relays sent that event back to the client. You can use on your posts to see which relays are receiving your events.
Yeah, It matters a lot. You need to know they are not going to delete your stuff and that your followers can connect to that relays to download your posts.
If they are private and your followers can't use them, it doesn't make sense to put there.
If they are just deleting everything you send because they think you are a spammer, then no one will see what you post.
Those relays are your home for your posts. Everyone of your followers will connect to them to download what you have to say. If the relay is fucking with them, then they are going to see what the relay wants them to see.
So, make sure you know what they are doing and you trust these relays.
Yeah, that list comes from the inbox relays the user is using. Amethyst for instance just adds them all. So if a user has 20+ inbox relays (which should be only 3), all 20 get into the list.
This is a general problem of poor relay management since many of those relay are offline or are paid and the user is not even paying for it.
Make Google search great again. On Nostr.
nostr:nevent1qqs28jyau5ejwx89nqspyzcv82fc8awtz3ddcyyeagfwcj4jlqyslrgpzpmhxue69uhkummnw3ezumt0d5hsygyehd2erjg3vcq0s3gs05clndv79a78uzdpl7qzap836s762472vspsgqqqqqqs7jrgk0
nostr:nprofile1qqs827g8dkd07zjvlhh60csytujgd3l9mz7x807xk3fewge7rwlukxgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgswaehxw309ahx7um5wghx6mmd9usjfpck got the same bug. It might be something that only happens when using the content provider.
Like on a computer? Amethyst needs fast connection because it tends to decrypt 1000s of events when you open it up. So, right now it would only work when the two apps are in the same phone.
I think Primal's image hosting service is massively capped on the number of simultaneous connections. Images on fresh posts (< 2mins) take forever to load because so many people are downloading at the same time. During that time, even if you open the link on the browser, it takes minutes for a 3MB image to load. If you let it pass a few mins, it comes back to normal speeds.
Nostr.build doesnt seem to have that problem.
FYI nostr:nprofile1qqsdv8emcke7k3qqaldwv956tstu40ejg663gdsaayuuujs6pknw7jspp4mhxue69uhkummn9ekx7mqpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpzfmhxue69uhhqatjwpkx2urpvuhx2uc86mqq0
Nice! I will keep an eye on it.
It seems to always happen when a new post with 2 or more ~3mb pictures are present and lots of people are on Nostr at that time.
I don't know if this is a server side or a CDN thing, but it has been quite a reliable "issue" from Boston.
Sure, but you don't need to know nips for that. Basically use Amethyst, 0xchat or coracle instead of damus and primal and problem solved. There is no need to track nips.
I did, but it's just basic stuff that doesnt really explain the protocol. I'd like to see a "NIP-01" type of doc that describes what's happening in each step along the way so I can re-implement it from near scratch.
This is great. I'd like to see it expanded to include everything I need to do to get a fully functional code out. No need to recode http, or mainline dht but any new protocol that pitches decentralization MUST offer a way to not use any of its own code if it wants to win. And implementers must have enough details to be interoperable with one another.
I am never going to build on top of a stack that I cannot understand to its core. And never going to build in a "decentralized" stack that is fully centralized in just one code base.
I am not saying that apps that use pubky must get together. I am saying that multiple (hundreds) implementers of the protocol behind pubky need to exist.
Otherwise, this is not decentralized at all.
This is no censorship resistance if we are all using the same code.
> Mainline DHT + DNS Parser + HTTP Client.
Yes. You told me, but I want to know EXACTLY how you integrate them all. I want to know all of the encodings so that if I code another implementation, your implementation must be able to see and parse my records.
At this point, there is no value proposion. It's just a bunch of jargon that doesn't clarify why this is better than other DHT-based approaches out there. As you probably know.... Many people have offered solutions in this space and ALL of them fail to deliver an actual decentralized DNS system. In fact, all of them just pitch a re-centralization on themselves via a web of new confusing nomenclatures. Which your proposal seems to do as well. I am giving you the benefit of the doubt, but the more I hear, the more I think you don't actually have anything actually decentralized.
I am also surprised to see how difficult getting information on this proposal has been. It almost looks like you don't want people using your thing.
We must have follow lists for each kind. The kind 1 follow list is different than a blog post follow list. So, all of your options are wrong. :)
Other kinds should never be rendered as root posts on kind 1 clients. But kind 1 clients must render or forward them when they are quoted into a kind 1.
If Nostr wins, I expect any user to have at least 30 clients being actively used in a single phone. If Nostr "micro apps" win, I expect over 100 clients for a regular user.
This is why App management clients are so important. No one will install 100 clients one by one. We must have some form of bundling that facilitates the integration of micro apps to do specific tasks.
No. The protocol is irrelevant. People want do join a cool community/app. They couldn't care less about the protocol. If you are explaining the protocol first, you are still talking inside our inner circles.
Then that app is to blame. If you sold that app as Nostr, the whole protocol is to blame. This is why people think Nostr is bad, even though what was bad was their experience with the first app, not nostr itself.
Oddbean new post about login | logout
Notes by Vitor Pamplona | export