Personally, I am in favor of a big tent - you want to promote Solid, come on in! At the same time though, we need to demand and evolve a concept of “the Solid spirit”.
So, welcome Togther+ crew and thanks for your work! Hopefully this discussion and ensuing discussions at Solid World will let us all collaborate on defining and manifesting the Solid spirit.
This is so great Charlie, thanks for sharing all that. I think it’s fantastic not just that you’re running the experiment, but are also sharing the challenges you encounter in public. That will help us all learn and hopefully tackle these challenges together. At least personally I’m looking forward to seeing how you move forward in your Solid journey, and what solutions you and others envision for the problems you so clearly outline. Again, thanks for sharing!
Thank you for your insightful comment, and welcome!
Personally, I am very happy to see Solid in a production-level beta.
At the same time, I would have loved to see the interoperability you say you had in mind.
I think you have a sound reasoning for doing everything within the BBC’s house,
especially when it comes to the security and privacy considerations.
However, I would like to comment on a few aspects (where others are invited to disagree and discuss!):
As the host of personal data in our pod provider, what might other applications do with that data?
Are we happy, as an organisation, absolving ourselves of the responsibility for that data when other applications use it, and is it legal to do so?
The question is if you - as a Pod Provider - are just a provider of access controlled web storage;
then you would be in the same position as, let’s say, Google Drive or Dropbox. None of these do - nor should, in my opinion - care what I do with the data stored there. I feel that most people (I talked to) think that this is the default.
On the other hand, if you consider the Pod Provider to be a data processor (as storage is processing) or data fiduciary, then you are in a whole different (legal) argument.
Trouble is, I was able to give another WebID of mine access to my BBC Pod and then access that data from a third party app. I was able to do this BECAUSE you designed your PoC in Solid style (e.g., the user setting access rights, the user patching data in resources etc). So, in the end, you did not achieve your goal with the design choices you made. Here, some more restrictive (and thus interoperability-impeding) approaches would be necessary which I would really dislike to see…
As the provider of a Solid app, do we also have responsibility for the data that is produced by that app? And if so, does that responsibility extend into other pod providers that might be connected?
That is a good question. I am genuinely curious about what legally literate people think about this.
However, if I may use a kinda strange analogy: A gun manufacturer is not liable for what other people do with said guns.
From a security perspective, the attack surface is larger when the pod provider and app accept new (or all) connecting implementations. Data inserted into a pod by another app may interact with our app in an unexpected or malicious way, and vice versa.
Agreed, and what is more, I agree that this is something you would want to rule out for a PoC.
In general however, I would think that you only use data you would want to use. If I think about the RDF you produce, you get the RDF from the Pod, you parse it, you query it and use only the part you want.
Can you give an example of data producing malicious behaviour of imperative code that is meant to process personal data? I am genuinely curious! 
It’s also worth thinking about the implications on the experience of a live service / app when the pod provider is entirely user-selectable [ … and the whole paragraph].
Take Mastodon, a federated micro-blogging platform, as an example.
Granted, UX for such stuff may be out of scope for a PoC but that would be totally understandable for those people who deliberately choose to use a different Pod provider than the BBC (even more if you just say: “Hey, choose us! When you use a different Pod provider, we cannot guarantee our service.”)
Additionally, even though the BBC is both the Pod Provider, and the App provider in this trial, these are fundamentally two different services, and user consent is required for the the app to have access to the Pod, in the same way as any app and Pod provider would interact [… and the whole paragraph]
Thank you, I noticed this while tinkering, and I did appreciate it! 
Good job on this!
So while I still question some design choices, I am really happy to see your work out in the wild!
Hi @charliehalford, thanks for joining the conversation and giving more insights into the conception of the app.
Although I disagree with some of the points you made, I totally understand your position and I think it’s great to see companies like the BBC diving into Solid. Many of the issues you raised are problems that the community hasn’t solved either, and I’m sure that use-cases like yours will help in shaping the way forward. Thanks for your work!
we designed the application using Solid and Solid concepts, whilst keeping in mind our duty as a public service organisation to keep our user’s data safe
I think this is the crux of our disagreement. You say it’s your duty to keep the users’ data safe, but the point of Solid is the opposite. If it’s the users’ data, it should be their choice where to keep it. If they chose you as guardians of their data, that’s great. But if you don’t give them a choice, you’re keeping the data hostage.
As you mentioned, being a POD provider and an app provider are two different things. And it’s true that given the current state of the Solid ecosystem, a company like yours is forced to fulfill both roles because there isn’t any POD provider that is ready for the public. So, from the POD provider’s point of view, I agree with everything you said.
But when it comes to the app, the fact that you don’t let users choose their own POD renders the whole point of Solid useless.
as you can see in the onboarding screens, we describe a world where this is possible, and exploring that world is why we produced this experiment
I have to say, this is one of the things that tripped me up the most whilst checking out the app. As I said, I understand your position and why you decided to take this approach. But then, I don’t understand why you’re exposing users to these concepts they can’t enact.
And I still think this onboarding screen is misleading, because there is a button saying “experience the future now”.
Finally, our answer to the question of is Together+ really a Solid app: We think so. Every aspect of the apps design has been looked at from a Solid perspective
This is also something I somewhat disagree with.
If we’re strictly talking about technology, sure, it’s an undeniable fact that BBC Together+ is a Solid App, because it uses the Solid protocol to move data around.
But, from the user’s point of view, I don’t think it’s a Solid App at all. @cbraun has mentioned that he’s been able to do some things with his data outside of the BBC, and that’s great. But I’m looking at the app from a user’s point of view, and I don’t see anything in this app that makes it different from any other app in the market.
If this is really a Solid App, where is my data? How can I access it outside of the BBC Together+ app? @Vincent also mentioned that he found his WebId in solid.bboxservices.net, but I haven’t seen any of that in the UI. So a user who understands what Solid is, but is not technical, wouldn’t be able to find this out. And even if they do, I don’t think they can use the WebId for anything because as far as I can tell, BBC Together+ is the only app they can use. At the very least, I expected to have access to a POD browser.
Just to be clear, as it stands right now, what do I have to do as a user to get my data? Do I have to send an email or something asking for a data export? How is that different from any other non-Solid App?
how is what BBC is doing, warranting such criticism, different from any other combo implementation out there? im aware there are likely some “pure” SOLID implementations (someone please link a list here) … but im curious .
I havent heard the same criticism put forth towards @gibsonf1 regarding Trinity and GraphMetrix even though they are a combo implementation whereby you cant be interoperable with their apps by hosting your own pod elsewhere (a different scenario from BBC but still a question of “pure” solid implementation) .
essentially the biggest players in the solid space currently are all doing centralized and integrated implementations … smaller players are building some more decentralized things assuming said infrastructure already exists .
The difference I see with GraphMetrix is that it does allow you to see your RDF data and interact with other apps. For example, I have been able to log in using a TrinPod account into my own apps, and then find the data my app created in their POD.
Although I guess that’s looking at it like a POD. If we look at Trinity as a Solid App I would agree with you, but I hadn’t considered it because I just saw Trinity as functionality on top of their POD. I do understand that POD providers will have their own functionality, otherwise POD providers would just be faceless servers that respond to the Solid Protocol.
Also, the BBC has a much bigger audience than GraphMetrix, and I think the reason why more people is interested is that it is one of the apps that was supposed to bring Solid into the mainstream. But in my opinion, using BBC Together+ you can’t do anything that you wouldn’t be able to do with a non Solid App.
In any case, this is just my opinion. And maybe the reason why other apps haven’t received criticism is that nobody raised the issue. If you’re interested in talking about any other particular Solid product, I suggest that you open a new thread to talk about it.
We got more insight into the project in last Thursday’s Solid World. If you missed it, you can watch the full recording here: Solid World November 2022.
There is a demo of the onboarding and usage of the app that is about 2 minutes long at 06:37, in case you want to learn more about how it works.
Seeing the video, it solved one of my doubts which was how to add friends. As I could gather, when someone creates a watch party, they get a link they can share with their friends using 3rd party channels. They can then use this link to join the party, and you can add people from the watch party to your friend’s list. As far as I could tell, the friends’ profiles do not expose the webId nor any Solid-specifics either. So this reinforces my opinion that Solid is just an implementation detail and this app could be implemented without using Solid at all.
Other than that, there are a couple more things I’d like to mention.
The first one is they shared some of the results of their research, and there is one in particular I’d like to comment. At 21:05 they say one of the UX challenges was that “people’s attitudes to controlling data don’t match their behaviour”. Although I understand the point, I think there are a couple of problems with reaching this conclusion.
One problem is that even if most people wouldn’t enact control over their data, and they really trust BBC to keep it, there will always be a small percentage of people who don’t. And the point of Solid is precisely letting this small percentage of people do it without hurting the majority (I still think the UX can be as good whilst respecting data ownership). This is the same idea as making websites accessible. There is probably a very small percentage of people who have accessibility requirements, but that doesn’t mean that we shouldn’t make websites accessible.
Another problem is that this part of the user journey is probably the worst one to gauge whether people want to do something with their data or not. It’s all sunshine and roses when you start using a service, but it’s really when you want to switch to another service or make it interoperable with another that you would enact your data control.
Other than UX challenges, I also wanted to comment on the reason why they are not allowing 3rd party PODs to use their app. They replied to this specific question at 46:15 (and allude to some comments they made at 19:22).
One of the things they mentioned is that RDF data is already exposed in the HTML markup, and they encouraged people to check that out, so that’s great.
They also mentioned that the main reasons why they aren’t opening up the POD are the existing policies at the BBC and some UX challenges. I don’t think the policies are going to change any time soon, so I understand not opening their POD to 3rd party apps. But hopefully their policies don’t prohibit using 3rd party PODs in their app, so the main blocker should be UX challenges.