Users define what relays they read from and write to in their relay list. Then clients know where to send notes when tagging specific people. Clients then also know where to read notes from when pulling their profile feed.
Timelines are a bit more tricky: you have to gather everyone you follow’s relay list somehow, then find the common relay subsets among all of them:
Alice, bob and jack are writing to relay A
Tom, Jerry are writing to relay B
phil is writing to A,C
Then your timeline feed is:
subscribe on A to alice,bob,jack,phil
subscribe on B to tom, jerry
With an algorithm that minimizes the total relays you connect to.
You’re also hoping these relays are reliable and have decent uptime.
Overall it might save a bit of upload bandwidth when querying, but it makes your client connect to a bunch of random relays that other users have defined in their profile. Many of which might be offline, unreliable or malicious. So you need to make sure your client is hardened against bad relays.
The dumbest way of doing it is damus’ original model that just reading and writing to relays in your relay list. It’s much simpler client-logic-wise but you have to manually add/remove relays to stay overlapped with your friends.
Login to reply
Replies (5)
This is a very good explanation. Thanks!
Thank you for explaining.
Regarding the connection to the unreliable and malicious relays what do you think about some sort of reliability checks on relays as an addition? (Historical performance, uptime, responsiveness etc. )
Advanced users should always able to PICK their OWN relays.
yes there will be bad boys and agency controlled relays admins too.
Entry level users will always stick whatever DEFAULT is given to them by the app or portal.
If I understood it properly: the scenario of malicious relays (planting a relay in a profile and baiting a user to tag in order to get their ip address) is something first time users (or non tech) might not be aware