Tekkadan, The Next Satoshi on Nostr: In my mind it should actually be quite simple, compared to what amethyst has already ...
In my mind it should actually be quite simple, compared to what amethyst has already accomplished, and not require significant reworking of much. From Vitor's responses so far, he is imagining a bigger scale undertaking with a lot more intricacies. It sounds cool for sure, but I think it deflates because multiple npubs already serves this purpose.
For me, Vitor's interpretation begs a new question. Which is, "how do you offer this type of seamless management for the rest of the NIPs?"
We're all dying to figure it out. But, I think the way amethyst relay configuration works is actually quite good. My suggestions break away local relays, which I believe helps. So, a followup suggestion to all of this, would be to break off "dm relays" and "search relays" into their own profiles. This would allow further management while also being able to completely disable and hide them upon kind-1 interactions.
All in all there is about 5-6 feature suggestions and changes within this overhaul, and some of them are still not fully detailed. But I believe this can completely work, and work well, while serving many different needs, AND while not disturbing the foundational way amethyst orchestrates our relay confirmations.
To note one final thing: the nip-66 importing would only be for POPULATING a profile. At this time, we don't "need" the profiles to be managed by nip-66, as the ecosystem is simply not ready for that yet.
I would be happy to talk about this in a voice/screenshare conference to expand on how these ideas cooperate with amethysts existing functionality, as typing and reading may not fully convey everything.
For me, Vitor's interpretation begs a new question. Which is, "how do you offer this type of seamless management for the rest of the NIPs?"
We're all dying to figure it out. But, I think the way amethyst relay configuration works is actually quite good. My suggestions break away local relays, which I believe helps. So, a followup suggestion to all of this, would be to break off "dm relays" and "search relays" into their own profiles. This would allow further management while also being able to completely disable and hide them upon kind-1 interactions.
All in all there is about 5-6 feature suggestions and changes within this overhaul, and some of them are still not fully detailed. But I believe this can completely work, and work well, while serving many different needs, AND while not disturbing the foundational way amethyst orchestrates our relay confirmations.
To note one final thing: the nip-66 importing would only be for POPULATING a profile. At this time, we don't "need" the profiles to be managed by nip-66, as the ecosystem is simply not ready for that yet.
I would be happy to talk about this in a voice/screenshare conference to expand on how these ideas cooperate with amethysts existing functionality, as typing and reading may not fully convey everything.