These relays should NEVER be in your Public Outbox (write) OR Public Inbox (read) relay lists. Please remove them.
relay.nsec.app
purplepag.es
sendit.nosflare.com
groups.fiatjaf.com
relay.getalby.com
inbox.nostr.wine
filter.nostr.wine/...
relay.groups.nip29.com
They are just wasting yours and your followers data plan. They are designed to go into other lists, not the regular ones you use in your client.
You can check your relays on https://metadata.nostr.com/
but what if you want to publish your profile to purplepag.es from amethyst? stuff like that, .. is how it ends up in an outbox. or would it publish to the general relays and you set it to general (and still get lots of rejections but at least your profile will update on the wider network).
im curious what will happen in the rewrite you are doing, will there still be general or not..
Yeah, that's the issue. But regardless, purplepages should never be in the outbox lists.
We might add an index list to send just the kind0 and kind 10002 there.
So, It cannot be in the general section too because otherwise it will just send everything to that relay.
last time i updated on metadata.nostr.com it sent the event to somewhere i never use and could only find on nostr.band, which i then queried with nak and sent to my actual relays..
so that's typically why i would use an app I trust more to do the update, and in amethyst at this time that means general or outbox. i also don't prefer having to publish a relay list of any kind just to use a relay..
Can we use only the Amethyst default suggestions and leave other relay groups empty?
Defaults are still good, but you need to choose outbox and inbox relays to host your content. Otherwise, we won't find you.
> We might add an index list to send just the kind0 and kind 10002 there.
Please not another event, we are scattering the basic profile config in too many places.
Maybe adding a "meta" flag to kind: 10002 is enough.
We are currently going in the opposite way. Even the Metadata event should not have nip05 and lightning addresses since those are not used by majority of Nostr applications. Sticking everything into just one event doesn't make much sense. The UI doesn't need to show different lists, but underneath it, there are dozens of lists already.
It's quite dispersive, IMO.
I should be able to fetch all the profile important stuff with a single REQ: basic metadata, outbox relays, DM relays.
> since those are not used by majority of Nostr applications.
This make little sense to me, doing a separate REQ to fetch a single piece of data of few bytes seems a waste of resources, and you have also to manage the case where the event is missing.
You can do the multiple kinds you need in just one REQ. I don't get the problem at all.
Sure, but you are still using more resources (from client and relay) than using a single event. What I don't grasp is this urgency to fracture the profile data, given its small size.
It's mostly PTSD from our massive follow lists and bookmark lists that break about half of the relays out there. We know shit breaks with large events.
Also, I would argue the opposite. Apps that don't use certain fields should not be forced to keep them in memory. Each app just downloads the exact content they need and leave bigger apps like Amethyst to suffer a bit with added memory. It's fine.
I never talked about following lists, these should stay separated, and maybe re-thinked to avoid the problems caused by the atomic structure.
About memory usage, we should reason keeping in consideration the real sizes: an average profile with 10 relays takes less than 1000 bytes, and the client can easily discard the useless data from memory as soon as it has been received.
Only if you need to download all the things, which most apps will never need to.
Everyone interacts with the same handful of people over and over. Just cache that data and background-sync it, periodically, so that the cache doesn't go stale.
The number of events is irrelevant, if you structure your fetches efficiently, and do some smart caching.
