So how should Opt-in work with R2R?
-
So how should Opt-in work with R2R?
Should it be that the source instance must explicitly register or give permission to the secondary relay?
Should it be the job of the primary relay to explicitly register with the secondary relay?
Should it be the job of the secondary relay to explicitly flag itself as a relay to the primary relay and send a relay request message to the primary relay?
How should the primary relay handle that permission?
-
So how should Opt-in work with R2R?
Should it be that the source instance must explicitly register or give permission to the secondary relay?
Should it be the job of the primary relay to explicitly register with the secondary relay?
Should it be the job of the secondary relay to explicitly flag itself as a relay to the primary relay and send a relay request message to the primary relay?
How should the primary relay handle that permission?
I think one way it could work is through opt-in chains.
Secondary relay(SR) identifies as relay and makes request to primary relay(PR) to relay PR's content.
PR asks source instance (SI) for permission.SI either grants permission or not.
If granted, PR grants permission to SR.SR relays SI content via PR.
-
I think one way it could work is through opt-in chains.
Secondary relay(SR) identifies as relay and makes request to primary relay(PR) to relay PR's content.
PR asks source instance (SI) for permission.SI either grants permission or not.
If granted, PR grants permission to SR.SR relays SI content via PR.
This can also be placed inside a closed registration-esque structure where only secondary relays which the primary relay has registered with can make the request to relay PR's content.
thereby reducing the number of requests to an SI to only SRs that are trusted by the PR.
But perhaps opt-in needs to be propagated further to individual user accounts.
-
This can also be placed inside a closed registration-esque structure where only secondary relays which the primary relay has registered with can make the request to relay PR's content.
thereby reducing the number of requests to an SI to only SRs that are trusted by the PR.
But perhaps opt-in needs to be propagated further to individual user accounts.
The other alternative is to delegate opt-in responsibilities to the primary relay.
Source Instances could set an option that says, you don't have to ask me for permission, I will leave it to you to decide whom to share my content with. Reducing the number of requests to users.
Or Source Instances could set a flag in the primary relay that says do not relay to secondary relays. (and don't ask me for permission because I won't ever grant it)
-
The other alternative is to delegate opt-in responsibilities to the primary relay.
Source Instances could set an option that says, you don't have to ask me for permission, I will leave it to you to decide whom to share my content with. Reducing the number of requests to users.
Or Source Instances could set a flag in the primary relay that says do not relay to secondary relays. (and don't ask me for permission because I won't ever grant it)
The problem of course as always is there's no way of enforcing bad actors from creating evil relays that pretend to be human accounts. But that's always been the case.
-
The other alternative is to delegate opt-in responsibilities to the primary relay.
Source Instances could set an option that says, you don't have to ask me for permission, I will leave it to you to decide whom to share my content with. Reducing the number of requests to users.
Or Source Instances could set a flag in the primary relay that says do not relay to secondary relays. (and don't ask me for permission because I won't ever grant it)
@OliviaVespera Each *actor* who wants their posts to be boosted by the bot should have to explicitly opt in, e.g. by following and/or private mentioning the bot's account, Web UI, ... There should be no server-level opt-in. Basically look at how @bsky.brid.gy does it.
-
@OliviaVespera Each *actor* who wants their posts to be boosted by the bot should have to explicitly opt in, e.g. by following and/or private mentioning the bot's account, Web UI, ... There should be no server-level opt-in. Basically look at how @bsky.brid.gy does it.
but it's not an actor -> bot connection.
It's an actor -> server -> relay -> secondary relay connection.
unless relays as they currently exist need to be fundamentally changed, they are currently opt-in as the instance level.
-
but it's not an actor -> bot connection.
It's an actor -> server -> relay -> secondary relay connection.
unless relays as they currently exist need to be fundamentally changed, they are currently opt-in as the instance level.
@OliviaVespera Consent needs to be explicit. The actor is the only one who can give consent.
-
@OliviaVespera Consent needs to be explicit. The actor is the only one who can give consent.
@teohhanhui i agree but are we talking about the same system here https://relaylist.com/
-
@teohhanhui i agree but are we talking about the same system here https://relaylist.com/
@teohhanhui Currently as it stands, relays are server level opt-ins.
-
@teohhanhui i agree but are we talking about the same system here https://relaylist.com/
@OliviaVespera Yeah, I think relays are a very bad idea and should not exist. But then, I also think *servers* should not exist.
-
@OliviaVespera Yeah, I think relays are a very bad idea and should not exist. But then, I also think *servers* should not exist.
@teohhanhui that's a much more fundamental conversation that would be nice to have but may not make sense in the case where relays are desired as is occurring with what happened recently.
I don't disagree and it's the final victory I'd like to see as described by @ifixcoinops 's parable. but we don't have that structure yet in the fediverse except with pocket/solo instances or activitypods.
-
@teohhanhui that's a much more fundamental conversation that would be nice to have but may not make sense in the case where relays are desired as is occurring with what happened recently.
I don't disagree and it's the final victory I'd like to see as described by @ifixcoinops 's parable. but we don't have that structure yet in the fediverse except with pocket/solo instances or activitypods.
> pocket/solo instances
But those are exactly the ones that need relays the most with the current topology of the Fediverse. So that's not really what I meant at all when I said servers shouldn't exist. Not to mention it's also too much of a technical / financial hurdle if people have to self-host instead of everything just being p2p.
-
> pocket/solo instances
But those are exactly the ones that need relays the most with the current topology of the Fediverse. So that's not really what I meant at all when I said servers shouldn't exist. Not to mention it's also too much of a technical / financial hurdle if people have to self-host instead of everything just being p2p.
@teohhanhui What did you mean when you said *servers* should not exist?
on them needing relays the most, it depends on your goal. As said, the parable is neat. -
@teohhanhui What did you mean when you said *servers* should not exist?
on them needing relays the most, it depends on your goal. As said, the parable is neat.@OliviaVespera Something like, Fediverse as p2p gossip swarm(s)?
-
@OliviaVespera Something like, Fediverse as p2p gossip swarm(s)?
@teohhanhui Can you describe it for me fully? I'm not familiar. And is it doable with ActivityPub or are we going much more fundamental?
Is there an example of a service/solution/software you're thinking of that exist you can share that would help me understand what you mean? -
@teohhanhui Can you describe it for me fully? I'm not familiar. And is it doable with ActivityPub or are we going much more fundamental?
Is there an example of a service/solution/software you're thinking of that exist you can share that would help me understand what you mean?@OliviaVespera Hmm I guess the closest analog would be BitTorrent. And in fact such a p2p Fediverse is very likely to reuse some of the technologies already successfully used by BitTorrent for a few decades, e.g. distributed hash table (DHT).
-
@OliviaVespera Hmm I guess the closest analog would be BitTorrent. And in fact such a p2p Fediverse is very likely to reuse some of the technologies already successfully used by BitTorrent for a few decades, e.g. distributed hash table (DHT).
@teohhanhui it just sounds like single or pocket instances to me, as they're pretty much peer to peer. and you're looking at technologiees outside of ActivityPub.
I'm not sold on anything that does not use ActivityPub in some measure. It's already been a struggle to build ActivityPub. I'm not really ready to unravel that protocol, except to augment it in the way ActivityPods suggests.
it does sound similar to the parable I pointed to.
-
but it's not an actor -> bot connection.
It's an actor -> server -> relay -> secondary relay connection.
unless relays as they currently exist need to be fundamentally changed, they are currently opt-in as the instance level.
This is true. I'm also for opt in, but this is server admin level so we must trust our server admins. So I agree that this is a R2R issue that needs to be solved on that level.
-
@teohhanhui it just sounds like single or pocket instances to me, as they're pretty much peer to peer. and you're looking at technologiees outside of ActivityPub.
I'm not sold on anything that does not use ActivityPub in some measure. It's already been a struggle to build ActivityPub. I'm not really ready to unravel that protocol, except to augment it in the way ActivityPods suggests.
it does sound similar to the parable I pointed to.
@OliviaVespera I'm out of my depth.
But if you're interested you can look into:
* https://codeberg.org/spritely/ocappub
* https://codeberg.org/spritely/golem
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi