Subscription exposure

[imaginator]

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 [email protected]).

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:

• [email protected] wants media item azab-romeo-hot-hot-hot-cdcd from [email protected]
• her bc-app requests a token from media.montague.lit
• media.montague.lit generates a token and sends a copy of the token to [email protected] and buddycloud.montague.lit
• buddycloud.montague.lit discards this token if [email protected] isn't a follower of romeo.montague.lit
• juliet tries to download from api.capulet.lit/media-proxy/[email protected]/media/azab-romeo-hot-hot-hot-cdcd by presenting the token.
• media.capulet.lit now checks that there is a matching token on buddycloud.capulet.lit
• if the token is still wasn't discarded by the buddycloud-server, the download proceeds.

I'm sure I've missed something?

[abmargb]

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:

• [email protected] generates the token herself
• she sends it to both the buddycloud server and the media server. This way [email protected] is telling the buddycloud server that whoever has this token can temporarily tell whether she subscribes to a node.
• the media server uses this token to check if [email protected] subscribes to [email protected]

[imaginator]

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 [email protected] generating the token.

@lloydwatkin @martin-hewitt - any thoughts?

[abmargb]

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.

[lloydwatkin]

@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 :)

[lloydwatkin]

Have been thinking about this a little, a similar to @abmargb's suggestion with a little modification of path:

1. User makes HTTP request to media server
2. Media server contacts relevant channel server
3. Channel server contacts user's channel server (may be the same machine)
4. Channel server sends the HTTP request approval denial

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.

[imaginator]

I love it when @lloydwatkin starts thinking!

[abmargb]

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?

[imaginator]

It belongs to the channel.

E.G. if you leave the channel/you leave the organisation, your contribution doesn't disappear.

[abmargb]

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?

[lloydwatkin]

It makes sense when I don't want the server to leak potentially sensitive subscription details.