change name and mission of the WG

[pchampin]

• This is a big PR (sorry).

I changed the name of the WG and deliverable to PUMPKIN (working title).

I mostly touched the first sections (Mission, Motivation & Background, Scope, Deliverables).
I refactored the text to make it more about the problem and less about the proposed solution. For the most, it is a reorganization of text that was already there, sometimes slightly rephrased, sometimes moved around (especially between the Motivation and Scope section).

The text that is really new compared to the previous version is highlighted in green to make it easier to review.

[TallTed]

Minor tweaks...

[melvincarvalho]

Why highlight these two? What is the user base, how many DAU? This looks weak, imho.

[pchampin]

Feel free to suggest others if you think they are more relevant. Those were the ones that I was most aware of, and which I believe the Solid community has interacted with in the past.

[melvincarvalho]

The use cases are in a bad state, not maintained and woefully out of date. Granted folks might not click through, but consider either making use cases more attractive, or removing this.

[csarven]

The use cases are there to serve as input for discussions. They are not in a "bad state" but surely they can be always better organised or be more "attractive". It serves its purpose for the charter in that the CG has done some homework. Removing goes counter the main takeaway here.

[melvincarvalho]

Do you think the use cases are in a good state?

https://github.com/solid/user-stories

If anyone clicks through, it gives a fairly unintuitive, wall of text, imho.

If anyone reading the charter works out that the user stories are in the issues tab, they will see this:

https://github.com/solid/user-stories/issues

At present time, it looks like a largely abandoned piece of work, with barely much activity over many years, and some people asking what's implemented without anyone having an answer.

It's OK if no one is going to look at it, but if someone does, would you consider it to be attractive, and well thought through?

[melvincarvalho]

inputs

[TallTed]

To the degree that they are discrete objects, and hence countable, inputs would be correct. I submit that the sentence here includes uncountable elements, and that input is therefore correct.

[pchampin]

Yep, it was meant as "uncountable" input.

[TallTed]

Suggested change

	The Working Group may consider other input, in addition to this specification, that is relevant to its scope and to the goal of this deliverable.
	The Working Group will consider other input, in addition to this specification, that is relevant to its scope and to the goal of this deliverable.

[melvincarvalho]

Yep, it was meant as "uncountable" input.

Got it, thanks!

[melvincarvalho]

Dont like this. Taking on too much. Could be done elsewhere.

[pchampin]

Again, this is not a work item.

Could be done elsewhere.

But in order to decide whether additional work needs to be done, and where (could be the new WG, could be the VC WG, could be a CG...), we need to discuss.

[melvincarvalho]

Generally like it. 3 comments:

• Consider another codename than PUMPKIN -- perhaps ask the mailing list?
• Have a compelling common understanding on Mission, as to what solid/pumpkin is, and what it does
• Consider removing some items, as I think it's taking on too much outside of the core, which will be hard enough to get to REC

[TallTed]

For what it's worth, PUMPKIN has a distinguished history as a codename, having served the first RDFCore working group as a codename for "node" which didn't then have a proper name.

[elf-pavlik]

Consider another codename than PUMPKIN -- perhaps ask the mailing list?

As I understand, the whole purpose of using placeholder PUMPKIN is not to get sidetracked into bikesheding the name at this point.

[csarven]

The use cases are there to serve as input for discussions. They are not in a "bad state" but surely they can be always better organised or be more "attractive". It serves its purpose for the charter in that the CG has done some homework. Removing goes counter the main takeaway here.

[jyasskin]

Minor comments:

[TallTed]

Suggested change

	<dd>To provide integration feedback on the use of WebIDs in PUMPKIN Protocol (and related technical reports) in order to stabilize the fundamental notions and behaviors.</dd>
	<dd>To provide integration feedback on the use of WebIDs in PUMPKIN Protocol (and related technical reports) to stabilize the fundamental notions and behaviors.</dd>

[pchampin]

I'd rather keep "in order to", which makes it easier for me to parse the relation between "to provide" and "to stabilize".

[melvincarvalho]

As I understand, the whole purpose of using placeholder PUMPKIN is not to get sidetracked into bikesheding the name at this point.

I can live with pumpkin, but it's raised a few eyebrows, and caused confusion because it sounds, imho, a bit unserious.

I could be wrong in that evaluation. Names can be important as they project an image, and choosing a name for something CAN be bike-shedding, but isnt always bike-shedding

Let me give an example response from someone that has followed Solid casually for a long time:

Obviously not the Cinderella story they expected

Some possible suggestions:

ACORN: Reflecting potential and growth, this name suggests the beginnings of something significant and expansive, much like the objectives of the SOLID project.

OAK: Symbolizing strength and stability, "OAK" could represent the robustness and reliability you aim for in your new spec.

IVY: Signifying growth and connection, "IVY" could represent the interlinked data and relationships facilitated by SOLID principles.

BEACON: Indicating guidance and illumination, this name suggests the spec's role in navigating new directions in web development.

VERTEX: Representing a peak or the highest point, "VERTEX" could symbolize the ambition of the SOLID project to achieve new heights in web standards and interoperability.

ORIGIN: Highlighting the foundational aspect of the project, this name suggests a new beginning or source from which further development can grow.

HORIZON: Signifying the exploration of new frontiers, "HORIZON" reflects the forward-looking nature of the SOLID project and its commitment to innovation.

Anyway I'll leave this as food for thought. I dont know how long PUMPKIN is going to stick around, but perhaps worth a quick thread on the mailing list.

[samuelgoto]

"global identifiers" doesn't seem to be something that is worth being proud of about?

[elf-pavlik]

Hi @samuelgoto, I would find it interesting to compare the use of WebID as a global identifier to the use of email addresses as a global identifier. In OIDC, email scope is very commonly used, and FedCM has email as part of user info.
Probably, we should pick a better venue for that comparison than this inline comment.

[samuelgoto]

Email addresses can be directed/sharded, rather than global.

[elf-pavlik]

People were looking into potentially similar approaches with WebId, such as https://kushaldas.in/categories/webid.html.
It would be great to document those practices in one place eventually. From my current standpoint, email addresses and WebIDs should be pretty comparable as identifiers.
Ultimately, people should be able to do what fits their needs, while correlatable shouldn't be the only option. Many individuals, probably even more organizations, want to establish a strong web identity. Even within the dev community, many people try to register the same handle across many online services.
Thinkin' about what can be realistically addressed in this or one of the next PRs here, maybe we should at least mention that the proposed WG should address known issues with correlatable identifiers. /cc @michielbdejong

[timbl]

I see people using IDs for Solid on a wide scale, between totally public like your linked in profile (I wrote about recently ) to single-use large random number IDs for whistle-blowing. In between, medium security IDs like alumni, club, and work emails, where some people know the correlation and some don't. Having a variety of IDPs o different types helps that.

It is important that this point in the Solid architecture is an extension pont so we can play with different authentication protocols, and support more than one at a time.

[TallTed]

@samuelgoto — Note that there is no restriction that any agent (especially, human) may only have n (which I think you read as 1) "global identifiers" (e.g., WebIDs) for themselves. I could have one WebID that I use for all my Rebel Alliance interactions, another that I use for all my Galactic Republic interactions, another that I use for all my Jedi interactions, and yet another that I use for all my Galactic Empire interactions. If and when I choose to announce that any two of these are co-referent to "me", I may choose to do so in one of those arenas, but remain distinct in the others. Key points are that the assertion/implication of coreference is my decision, and that none of these incorporate a mandated "phone home" except in the course of dereferencing that WebID in order to confirm the user's assertion of control therof — which is a known activity.

"Global identity" can be "something that is worth being proud of", especially as it allows pseudonymous activity that is interpreted only based on that activity, and not based on the fact that, e.g., the pseudonymous author is 12 years old. (See some discussion of this in OSC's Ender series, particularly e.g., Valentine Wiggin, under her pseudonym Demosthenes, publishes.)

[TallTed]

@samuelgoto — Also note that WebIDs can also be "directed/sharded" (i.e., they can indirectly identify an agent-in-a-role, like "CEO of Company_X" or a group-that-acts-as-a-singular, like "BoD of Company_X" where any Board member can act on the Board's behalf).

[samuelgoto]

Maybe you should call these "unique" rather than "global" then?

[TallTed]

They're "global" because (HTTP/S-)URI-based identifiers (like WebID) offer dereferenceability as a feature, always being resolvable to descriptions of the identified agent/entity. This dereferenceability is available anywhere, anytime, to anyone — though there might be some dereferences which require authentication by the caller in order to get that description, and some which can only be completed when the caller is within a VPN or similar, etc.

As to "unique", that refers to the identified agent/entity (i.e., the identifier identifies a unique agent/entity. People often get confused, and think the WebID identifier cannot be lexically repeated, as with UUIDs/GUIDs), and is only guaranteed within a timestamp, because domain registrations change, among other things. Within that timestamp, however, they are intended to uniquely identify an entity/agent, such that anyone who refers to a given WebID (or similar) is understood to intend to mean the same entity/agent.

Outside the bounds of the indeterminate timestamp, the agent/entity identified by the WebID (or similar) may differ — but the descriptions of the "earlier" and "later" entities/agents are expected to include sufficient detail — such as timestamps of description creation, modification, termination — that the dereferencer can handle each

[jyasskin]

The quote about "to describe the interoperability" doesn't seem like it actually describes the shared goal across Solid, IndieWeb, and Unhosted. I think you actually want to improve the interoperability, not just describe it? And the list of things you want to use aren't focused on the scope you want this WG to have. Can you tighten it, even if you can't quote the CG's mission statement anymore?

[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.

Suggested change

	<span class=new>The scope of the Working Group is to define a web protocol for use between client-side applications, on the one hand, and storage and identity servers, on the other, allowing</span> users to keep authority over their data, identity, and privacy.
	<span class=new>The scope of the Working Group is to define a web protocol that client-side applications can use to authenticate users and store their data with user-chosen identity and storage servers. Applications that use this protocol can more easily allow their users to keep authority over their data, identity, and privacy.</span>

[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.

• Users can use any app with any pod.
• Choice of app and choice of pod are independent. So two new markets.
• Users can control who has access to their data.
• Developers can write apps without having to change the code running on a server.

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]

Applications that use this protocol can more easily allow their users to keep authority over their data, identity, and privacy

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]

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 protocol itself allows the user to retain authority over their data.

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]

login with email URIs

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.

[cwilso]

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]

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.

Excellent point. If the original web was "used correctly" many of the pervasive issues we see today would not exist.

Choice of app and choice of pod are independent. So two new markets.

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.

[pchampin]

@jyasskin for the sake of usability, I'll turn this suggestion (+ the following thread) into a separate PR.

[jyasskin]

This text isn't sufficient to let the WG adopt these deliverables without rechartering, but I'm worried that isn't clear enough. Perhaps:

Suggested change

	adequate implementation experience</a>, the Group may also decide to adopt the following dependencies as input documents:</p>
	adequate implementation experience</a>, the Group may also decide to recharter to add deliverables for the following dependencies:</p>

[pchampin]

@jyasskin thanks for this suggestion, which highlights a lack of clarity in the charter. In my view, (at least some of) the specs listed below are in scope of the Solid Protocol at large, so the group should have the ability to use them and include the result in the Solid Protocol deliverable (even if that means splitting the deliverable in several parts) without rechartering. Obviously, this is not clear enough. I'll merge this PR, then make a separate PR to clarify this particular point.

[csarven]

Putting the following suggestion on the table following https://github.com/solid/solid-wg-charter/pull/69/files#r1533485709 with the understanding that it'd be useful to have on record genuine intentions of the charter proposal:

Suggested change

	<b>Input document</b>: <a href="https://solidproject.org/ED/protocol">Solid Protocol, latest published version (0.10.0) or Editor's Draft</a>, adopted from the <a href="https://www.w3.org/groups/cg/solid">W3C Solid Community Group</a>.
	<b>Input documents</b>: <a href="https://solidproject.org/ED/protocol">Solid Protocol, latest published version (0.10.0) or Editor's Draft</a>, adopted from <a href="https://www.w3.org/groups/cg/solid">W3C Solid Community Group</a>; <a href="https://fcrepo.github.io/fcrepo-specification/">Fedora API Specification 1.0</a>.

For those that may be unfamiliar with the Fedora API Specification, the gist of the relevancy is that it extends LDP and is generally compatible with the Solid Protocol (similar roots.) It has a solution for various deliberations that were raised in the Solid Protocol. It also normatively references Web Access Control: https://solid.github.io/web-access-control-spec/ , which is also normatively referenced in the Solid Protocol. So, this is all highly useful and constructive input.

That said, whether the inclusion of this potential input needs to meet a certain criteria, that'd be good to note here, e.g., does it actually need the "approval" of the Fedora Commons/Project to be mentioned in the charter, or can the charter or the WG simply re-use/borrow/incorporate recommendations from the Fedora API Specification 1.0 (CC BY 4.0 licensed) towards "a protocol specification" - I don't see why not but the Solid CG and W3C Team/community can make that call and put it on record.

[cwilso]

This seems like an unclear formatting: it says "Solid spec, adopted from SolidCG, Fedora API spec". I think you mean "Solid spec, adopted from Solid CG; Fedora API spec"? or bullets, or something.

I think the biggest concern would be provenance of Fedora features and IPR coverage; not that such is impossible to resolve, just needs to be done.

[pchampin]

For the sake of usability, I'll turn this suggestion into a separate PR.

[melvincarvalho]

@timbl the innovation of Solid is to make the web Turing Complete, but no one is saying that. Once the web is Turing Complete, then, over the course of time, it can be pushed to its limits. There is a natural tendency for technologies to be pushed to their limits over time. I'm sure you know this, but it's not that well articulated. By making the the web Turing complete, any application you can imagine can be built. That's the innovation, and why it should go to WG and be a REC. Cut out what's unnecessary, and keep this one magical property.

[TallTed]

Merged directly to this PR, without time to review

Too many "it(s)" with indeterminate antecedents.

Suggested change

	The Working Group will consider other input, in addition to this specification, if it deems it relevant to its scope and to the goal of this deliverable.
	The Working Group will consider other input, in addition to this specification, if the Working Group deems that input to be within the scope of its charter and relevant to the goals of its deliverables.