Add screen to select individual relays when posting/broadcasting

[devandsev]

Adds BroadcastToRelaysView screen to select individual relays to which the event will be sent. Can be presented from 3 places (posting, replying, broadcasting). There are "All" and "One" buttons for quick selection. New PostView's "Relays" button has a dashed stroke if not all of the relays are selected.

Together with https://github.com/damus-io/damus/pull/289 it can be a good start towards more granular approach in managing relays.

Minor changes:

• Moved PostView's "Cancel" and "Post" buttons to navigation bar
• PostView's button is always visible, but is being disabled if the post is empty (used to be hidden in this case).

New post:

https://user-images.githubusercontent.com/17564071/216797412-fd9c5e32-83f7-415f-acd2-718d0a7b998c.mp4

---

Replying:

https://user-images.githubusercontent.com/17564071/216797421-7315889c-68da-429f-b15b-630487737ed2.mp4

---

Broadcasting:

https://user-images.githubusercontent.com/17564071/216797425-d0dc0b36-d177-4883-89f4-6e9196769b21.mp4

---

[alltheseas]

Who is the user, and what is the user story here? Would the typical nostr/Damus user utilize this feature? How would you explain this to a Damus newbie?

[devandsev]

User may want to use different relays for different purposes, there may be a relay for local event/conference, or a private relay for a group of friends, and you wouldn't want to leak your posts to public relays. I've seen people discussing this on Nostr recently.

It's definitely not a feature for a total newbie, oblivious to what Nostr is, but Damus already exposes relays list via side menu and so far it hasn't caused any major confusion. So it's not different in this regard, user is free to ignore relays as a concept and use the app with default settings (hiding some stuff behind "Advanced mode" toggle in the settings is an option here).

As I understood, eventually you'll be able to connect to/disconnect from individual relays and even group relays together in relay sets note1y6uksu0g6hypedla9pu3fdf59rqza458esqnr3hthk438lz6rltsr4n9ay. I imagine going into Settings to change to which relays you are connected to before making a post will be cumbersome. Just starting a post and selecting relays before posting seems much more convenient.

[alltheseas]

Thanks for the detailed response. I like the described broadcast functionality for advanced users as well. Here is my go at writing the user story, as you described.

User Story

As an advanced Damus user who wants to broadcast to a particular set of users, I want to explicitly select which group I am broadcasting to (via relay), so that I only broadcast to the intended group.

Here is the Relay Sets feature request I wrote up: https://github.com/damus-io/damus/issues/453, including a basic toggle between relay sets mockup of the timeline view.

I wonder if you could combine #289 with this PR in the context of relay sets.

In relay/advanced settings user could pre-define the relay sets - using the examples you provided for example - A) private friends group B) private in-person conference group C) public / global relay group

Back in the main/timeline view, you can toggle between relay set A, B, or C. Your network view, and audience is indicated.

If you are on relay set A, then you only see (#289) notes from & broadcast (#525) notes to relay set A. If you are on relay set B, then you only see & broadcast to relay set B. If you are on relay set C, then you only see & broadcast to relay set C.

And so on.

[devandsev]

Thanks for structuring it, that's exactly what I had in mind.

If it makes sense to combine https://github.com/damus-io/damus/pull/525 (this PR) with https://github.com/damus-io/damus/pull/289, my PR can be merged in at any time if there are no requests to change how it looks/works, it's pretty self-contained.

However, I think the relays list component should be reused (it's named BroadcastToRelaysView in this PR, can be renamed) with some tweaks to accommodate both use cases. One way to go about it is to merge https://github.com/damus-io/damus/pull/525 to a dedicated feature branch granular-relays, then base this PRs https://github.com/damus-io/damus/pull/289 branch of granular-relays and reuse BroadcastToRelaysView. After merging the second PR we can work on relay sets in the same granular-relays branch. I think it would be easier to make these incremental changes and when everything is done merge granular-relays to master. So it'll look like this:

1. Create granular-relays branch
2. Merge https://github.com/damus-io/damus/pull/525 to granular-relays
3. Base https://github.com/damus-io/damus/pull/289 of granular-relays
4. Work on https://github.com/damus-io/damus/pull/289 a. Add source relay data to each event model https://github.com/damus-io/damus/pull/289#issuecomment-1377540466 b. Decide how we would like to move forward (disconnecting relays or just filtering) https://github.com/damus-io/damus/pull/289#issuecomment-1382210324
5. Merge https://github.com/damus-io/damus/pull/289 to granular-relays
6. Work on relay sets and merge to granular-relays. (Optionally relay sets can be a standalone feature planned for a future release)
7. Merge granular-relays to main

Also we have to choose which UI would be a better fit. I chose checkmarks instead of UISwitch because this way the whole cell is tappable, no need to aim for the toggle specifically.

[jb55]

gonna merge this, I think it's pretty cool.

[jb55]

had to revert this because it doesn't interact well with @ autocompletion

[BenGWeeks]

We did some design thinking around this @SashaPavlova which we should revisit in the new design. At the time, we were thinking around the "pay to post" concept where you pick the relays and some of them were paid. However, that commercial model hasn't appeared yet. Also, I think it should be an option to pick that you can open, rather than a forced additional step to post. The relays you post to should be the same as the filter currently appeared. FYI @robagreda @alltheseas

See related comments in https://github.com/damus-io/damus/pull/289