Communities can switch relays by switching relays. It's the same as switching pubkeys would be, there has to be an authoritative identity. If that has to change, then it has to change. Pubkeys can't be censored by DNS, but they're harder to change. It's a trade-off, but communities need a host in any case, so it's easier to start there. Once you select a relay url, you can follow its pubkey to get updates on the relay's new location, then update your memberships from there.
I don't understand your second question. I don't know what a targeted publication is, but if it needs to be replaceable then model it that way.
Cross-posting doesn't have to be surfaced in the UX. Just create multiple events under the hood, like we do with DMs. When you DM someone, two events get published, but it only ever shows up as one message. Just have a button that says "post to x, y, z communities". Depending on how you do it, you might publish one event to multiple relays, a root event to your relay with three reposts with h tags, or just three copies of the event each with a different h tag. All three are legitimate approaches.
A relay is a service.
I need to be able to switch service provider, at any time.
When you make the relay url the ID, you need to own a domain name to switch services under the hood. And even then, you're still not really sovereign.
When you make the key the ID, you only need that to switch relay, blossom server, mint, etc... Same pattern for everything. Same pattern to teach my customers, once.
I'm not talking about switching IDs.
That's the same problem/opportunity we have for profiles in general.
Thread collapsed
True, crossposting and all the other things you list can be hidden and can work. They're just in no way as simple and transparent as the Targeted Publication event I propose.
Thread collapsed
