For those reasons, I think your proposition is not a good solution. I’ll try to propose something else soon.
This is not a proposition any more. It stopped being one when I changed the original one not to depend on the core so much. Right now it depends on only the carbon copying of posts outwards - even if that which is now in develop was reverted I could do a single commit patch which podmins could pull in if they want.
So this is pretty much live now, just not fully functional. I already see diasporapr.tk sending posts out to the relay I’ll push the latest changes to the relay live early next week so posts will be relayed for the first time and start real world testing.
[Warn] External dependency for a core feature is dangerous.
It’s not a core feature. The core feature is to NOT deliver posts by design to all pods. And that works and will continue to work.
[Warn] On the same topic, to use a centralized list of pods is a potential vector of attack / problem. We’re loosing part of the force of diaspora* here.
Part 2 would be decentralizing the relays themselves. Initially yes each pod configuring a single relay makes it weaker. But less weaker than pod email delivery or hosting, which is the weakest part of diaspora, users being locked into a single server for life. And since this is not a core feature, like user login is…
[Warn] Pods are not equal anymore.
They are even less equal now. Right now it makes sense to join a large pod, to see many public posts. Setting up your own pod doesn’t make sense. Using relays will make pods more equal.
But, the relay will also enable pods to be more strongly themed, for example a pod could subscribe to only linux and open source posts, ignoring all the other stuff.
[Blocking] The interactions on posts that are transmitted by relay are not federated.
Well, the same problem is with reshares. And the interactions can be solved, just have to decide which way to go, to relay them or to only use relays for the initial post delivery. I think only using this in real world will tell which is better. Anyway, it needs to happen before 0.6 is released and also before that the participations bloat needs to be dealt with and the federation tuned to be more efficient. Will be submitting something for both these for consideration.
I don’t see the point of displaying a post if I know that only the users of my pod will see my reaction on it.
Not entirely true. Since a pod which gets a post via a relay will fetch the author contact (by diaspora protocol design), interactions will be sent to the original pod as if the pod had delivered the post. The problem is that afaict the original pod will only relay the interaction as normal, not to other pods that depend on relays. This is how I understand it:
- pod A <— author of post
- pod B <— contact of pod A author
- pod C <— not in contact with pod A author
- pod D <— not in contact with pod A author
So when pod A author sends a post it will be delivered to pod B user directly and pod C and pod D users via relay (assuming both subscribe in this case).
Initial relay concept doesn’t relay interactions, so when a user on any of the pods comments:
- pod A will receive it
- pod B will receive it (since pod A relays it)
- pod C will not receive it (unless done from pod C)
- pod D will not receive it (unless done from pod D)
But this situation is fixable by defining whose responsibility is to do what. Of course, either the relay should take care of whatever “broken” links it creates OR it should create participations so that interactions flow as they should. Though as said, the current reshare concept also has these kind of bugs.
Thanks for your comments and while I’m looking forward to seeing a proposal to the core that would solve federating all posts to whoever wants them but allow still pods to not receive all posts, I really doubt that kind of solution is doable to the core and it wouldn’t even make sense to bloat the core with it.