melvincarvalho
commented
3 months ago Unsure if this is a discussion or for comment on the PR text.
The PR text is truly excellent. It reads very well.
Slight nit is that it can be used with server side apps too. In fact in the end server side may be more than client side. However, I dont see that the text needs changing.
Re: Does the value come from the protocol or the applications?
Both.
-
In the short term people are "running away" from certain parts of the web. From apps, sites, servers and algorithms that control you and invade your privacy. Apps can offer a degree of control more than before, with the federated model. Though federated is still co-owned with your provider, and identity provider. It is an incremental step forward.
-
In the longer-term people are "running towards" something because it offers new functionalities, new innovations, new ideas not seen before on other parts of the web. The idea of humans and machines working together in a linked space under user control, and importantly, offering censorship-resistance, and other features not offered in the mainstream web. That is where, if done well, the protocol can play a role.
Stage (1) comes first, then stage (2) comes later, if all goes well.
elf-pavlik
csarven
pchampin
TallTed
suggested by @jyasskin in https://github.com/solid/solid-wg-charter/pull/69/files#r1529416046
Conversation copied below:
@jyasskin I think "define a web protocol ... allowing users to keep authority over their data, identity, and privacy." skips an important intermediate step. In particular, the protocol itself can't allow users to do anything. Instead, it helps application developers make some choices that are better for users.
@timbl a) It is an internet protocol. (what is a web protocol? an internet protocol based on HTTP? ok) I have always used "internet protocol" defined as the syntax and semantics and sequence of communication between different hosts on the Internet. HTTP, FTP are internet protocols Solid is a more powerful one based on HTTP.
b) The protocol design gives you value. It provides things which are true if you follow it. If you use HTTP, .. eg ..you never don't overwrite other people's changes to a resource, caches work, and so on. If you use Solid correctly you get these properties.
and so on. When we charter the group in a way the most important thing may be that we are chartering it to provide those beneficial properties of the Solid ecosystem built on top of the Solid Protocol as a new platform
@elf-pavlik
I wouldn't formulate it this way. It is the user who allows and denies applications access to specific data at will. On the one hand, applications are the most crucial part responsible for UX, but on the other hand, they are the least trusted and privileged part of the ecosystem. The original sentence captures it better: The protocol itself allows the user to retain authority over their data.
@melvincarvalho
The architecture of the ecosystem places pod providers at the apex of trust and privilege, following a federated model. This is not theoretical, we have witnessed it over and over in the federated model.
Subsequently, identity providers operate within a trusted third-party framework. Again this has brought centralization power to large centralized players on the web (typically email providers, which is a reason that login with email URIs is pushed so aggressively, often to the exclusion of all else).
It's worth noting that the previous integration of WebID-TLS offered more user agency, allowing sever-side support without compromising functionality. The addition of OIDC, despite initial assurances of coexistence, unfortunately led to the quiet deactivation of WebID-TLS, on the server side, a move that seems to lack a technical rationale. When the OIDC folks removed WebID-TLS from the client side, they quietly removed it from the server side, without any mandate to do so. Turning back on WebID-TLS on the server side, which should never have been removed, would help improve this situation.
This decision underscores the inherent risk of optionality in technology standards, where political dynamics may influence technical decisions, another reason why it's important to have a well defined identity system based on web protocols ie HTTP URIs, at least at this point, and not open the door to optionality in identity, in the WG, which can quickly become political.
In short, despite the wording in the charter, the user is in 3rd place in terms of agency. The pod owner is first, and has complete authority, including to cancel any user. The identity provider then has power over the user, can impersonate the user, can silently track all user activity. After that the user can add permissioned access control. This is very useful and can lead to a web operating system, but that's not quite what's communicated in the charter, at this point.
@TallTed
Doesn't really exist. It's login with email addresses. Yes, those addresses are trivially converted to URIs (by prepending the
mailto:scheme), but without that conversion, they remain addresses. Referring to them as "email URIs" does no-one any favors.@cwilson
I think my biggest concern here is buried in "if you use Solid correctly". That's not just if the user uses Solid correctly - it's relying on all app developers and other participants in the ecosystem to honor an (implicit?) pattern.
@melvincarvalho
Excellent point. If the original web was "used correctly" many of the pervasive issues we see today would not exist.
Solid's app model, right now, is not incentivized. Adverts can be blocked. What is the incentive to use solid "correctly" for app makers? The incentives are more aligned to couple apps and server together, and track users. As someone that works with advanced client side apps every day, I can say it's extremely challenging for any apps to get any sustainable revenue. In a competitive app market most of the apps will not cover their costs, leading to some dominant players, if at all. Even more importantly there is the "king maker" effect. In short, there are incentives missing for solid to be "used correctly". As the app ecosystem matures, this will become more apparent. For example how would you do advertising on a solid app, when it's easy to remove?
I think what's missing in the list is not the loose coupling of apps (this exists today elsewhere), but rather the power of apps working together on client and server side. I think the idea of a web operating system could be explained more.