Open imaginator opened 10 years ago
Why would buddycloud.montague.lit
trust media.montague.lit
in a way that it'd provide private subscription data to the latter?
The way I see it working:
juliet@capulet.lit
generates the token herself juliet@capulet.lit
is telling the buddycloud server that whoever has this token can temporarily tell whether she subscribes to a node.juliet@capulet.lit
subscribes to romeo@montague.lit
Why would buddycloud.montague.lit trust media.montague.lit in a way that it'd provide private subscription data to the latter?
I'd have expected that the buddycloud-server would trust a media server on it's own domain.
But that said, I like your idea of juliet@capulet.lit
generating the token.
@lloydwatkin @martin-hewitt - any thoughts?
I'd have expected that the buddycloud-server would trust a media server on it's own domain.
That'd would work for a local media server, but in this case we could've configured the buddycloud-server with an admin jid that could access private subscriptions. This discussion was motivated by remote media servers trying to access those.
@abmargb's method sounds like a good way to do it, but it also sounds like a lot of added complexity, and I'm also thinking race conditions.
Off the top of my head I can't think of anything better right now. I suggest a sponsored 'buddycloud on the beach' in Brazil to mull this over :)
Have been thinking about this a little, a similar to @abmargb's suggestion with a little modification of path:
At stage 2 the channel server can decide to return a deny before it even gets to the user. No exposure of the subscription information, and no leakage of where the deny came from.
I love it when @lloydwatkin starts thinking!
I was thinking a little more on the origin of this discussion and I ended with a question: does the media belong to the user who uploaded it or to the channel where it was uploaded to?
It belongs to the channel.
E.G. if you leave the channel/you leave the organisation, your contribution doesn't disappear.
Making it a little more clear: this feature makes sense when we have multiple buddycloud enabled domains being served by a single media server, right?
It makes sense when I don't want the server to leak potentially sensitive subscription details.
To make media sharing work, it's necessary to expose subscriptions to private channels.
This is not ideal (e.g. exposing followers of the private channel
breast-cancer-support@example.com
).But the media server needs to know if you follow something before being able to issue a download token. Also for remote media servers.
Would the following work as a potential solution:
juliet@capulet.lit
wants media itemazab-romeo-hot-hot-hot-cdcd
fromromeo@montague.lit
media.montague.lit
media.montague.lit
generates a token and sends a copy of the token tojuliet@capulet.lit
andbuddycloud.montague.lit
buddycloud.montague.lit
discards this token ifjuliet@capulet.lit
isn't a follower ofromeo.montague.lit
api.capulet.lit/media-proxy/romeo@montague.lit/media/azab-romeo-hot-hot-hot-cdcd
by presenting the token.media.capulet.lit
now checks that there is a matching token onbuddycloud.capulet.lit
I'm sure I've missed something?