-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
change name and mission of the WG #69
Conversation
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor tweaks...
charter/index.html
Outdated
<li>Interoperability between applications and various storage server implementations of the protocol.</li> | ||
<li>A decentralized trust model enabling authentication and authorization mechanisms across the web.</li> | ||
</ul> | ||
<p><span class=new>A number of initiatives, such as <a href="https://indieweb.org/">IndieWeb</a>, <a href="https://www.w3.org/community/unhosted/">Unhosted</a> and <a href="https://solidproject.org/">Solid</a>, have emerged to propose alternative models for web applications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why highlight these two? What is the user base, how many DAU? This looks weak, imho.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
charter/index.html
Outdated
<p> | ||
The Working Group will: | ||
Based on the <a href="https://github.com/solid/user-stories">user cases</a> identified by the Solid project, potentially extended by Working Group participants, the Working Group will: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
charter/index.html
Outdated
<p> | ||
The Solid Protocol may include protocol details for integration with identity layers and mechanisms; access management and data integrity; notifications about resource changes; and, authorization mechanisms. | ||
<p class=new> | ||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
inputs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, it was meant as "uncountable" input.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, it was meant as "uncountable" input.
Got it, thanks!
charter/index.html
Outdated
|
||
<dt><a href="https://www.w3.org/groups/wg/vc">Verifiable Credentials Working Group</a></dt> | ||
<dd>To inquire on the suitability of credentials data models and serializations, and their potential integration with the Solid Protocol.</dd> | ||
<dd>To inquire on the suitability of credentials data models and serializations, and their potential integration with the PUMPKIN Protocol.</dd> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dont like this. Taking on too much. Could be done elsewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Generally like it. 3 comments:
|
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. |
As I understand, the whole purpose of using placeholder PUMPKIN is not to get sidetracked into bikesheding the name at this point. |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
charter/index.html
Outdated
<p> | ||
The Working Group will: | ||
Based on the <a href="https://github.com/solid/user-stories">user cases</a> identified by the Solid project, potentially extended by Working Group participants, the Working Group will: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments:
|
||
<dt><a href="https://www.w3.org/groups/cg/webid">WebID Community Group</a></dt> | ||
<dd>To provide integration feedback on the use of WebIDs in Solid Protocol (and related technical reports) in order to stabilise the fundamental notions and behaviors.</dd> | ||
<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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather keep "in order to", which makes it easier for me to parse the relation between "to provide" and "to stabilize".
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:
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. |
charter/index.html
Outdated
<p><span class=new>A number of initiatives — such as <a href="https://indieweb.org/">IndieWeb</a>, <a href="https://www.w3.org/community/unhosted/">Unhosted</a>, and <a href="https://solidproject.org/">Solid</a> — have emerged to propose alternative models for web applications. | ||
They are</span> largely based on existing open web standards, which they extend to give priority to individual and group autonomy.</p> | ||
|
||
<p>The <a href="https://www.w3.org/groups/cg/solid">W3C Solid Community Group</a> has been incubating <a href="https://solidproject.org/TR/">specifications</a> since 2018 towards that end, i.e., <q cite="https://www.w3.org/groups/cg/solid">to describe the interoperability between different classes of products by using web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces.</q> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"global identifiers" doesn't seem to be something that is worth being proud of about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Email addresses can be directed/sharded, rather than global.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you should call these "unique" rather than "global" then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
charter/index.html
Outdated
<p><span class=new>A number of initiatives — such as <a href="https://indieweb.org/">IndieWeb</a>, <a href="https://www.w3.org/community/unhosted/">Unhosted</a>, and <a href="https://solidproject.org/">Solid</a> — have emerged to propose alternative models for web applications. | ||
They are</span> largely based on existing open web standards, which they extend to give priority to individual and group autonomy.</p> | ||
|
||
<p>The <a href="https://www.w3.org/groups/cg/solid">W3C Solid Community Group</a> has been incubating <a href="https://solidproject.org/TR/">specifications</a> since 2018 towards that end, i.e., <q cite="https://www.w3.org/groups/cg/solid">to describe the interoperability between different classes of products by using web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces.</q> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
<p> | ||
The design approach for the <a href="https://solidproject.org/TR/protocol">Solid Protocol</a> will continue substantial efforts undertaken previously in the <a href="https://www.w3.org/groups/cg/solid">W3C Solid Community Group</a> to specify a set of interoperable protocol standards for enabling the use and development of Solid servers and applications across a <a href="https://github.com/solid/user-stories">wide range of use cases</a>. | ||
<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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
<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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jyasskin for the sake of usability, I'll turn this suggestion (+ the following thread) into a separate PR.
@@ -267,7 +270,7 @@ <h3> | |||
<section id="dependencies"> | |||
<h3>Dependencies</h3> | |||
|
|||
<p>The proposed adopted draft for the Solid Protocol has a number of normative dependencies with a maturity level insufficient for a recommendation (Community Group reports, Editor's Drafts). The Working Group will need to decide how to deal with these dependencies in order to allow the Solid Protocol v1.0 to progress on the Recommendation track. This may include downgrading those dependencies to non-normative references, specifying the required parts in the Solid Protocol itself, or relying on other specifications to fulfil the same purpose.</p> | |||
<p>The draft of the PUMPKIN Protocol proposed for adoption has a number of normative dependencies with maturity levels insufficient for a recommendation (e.g., Community Group reports, Editor's Drafts). The Working Group will need to decide how to deal with these dependencies in order to allow the PUMPKIN Protocol v1.0 to progress on the Recommendation track. This may include downgrading some of these dependencies to non-normative references; specifying the required parts in the PUMPKIN Protocol itself; and/or relying on other specifications to fulfill the same purpose.</p> | |||
|
|||
<p>Depending on the Working Group progress, including consideration for <a href="https://www.w3.org/Consortium/Process/#adequate-implementation"> | |||
adequate implementation experience</a>, the Group may also decide to adopt the following dependencies as input documents:</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This text isn't sufficient to let the WG adopt these deliverables without rechartering, but I'm worried that isn't clear enough. Perhaps:
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> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
</p> | ||
<p> | ||
When possible, the Solid Protocol will evolve while maintaining a high degree of compatibility with existing implementations, of both servers and clients, and with features from prior versions. If incompatible changes have to be made, then they will be done by introducing a stage where both old and new protocols are supported, to allow the implementors to upgrade their systems in a managed way. | ||
<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>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
<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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the sake of usability, I'll turn this suggestion into a separate PR.
@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. |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
See whatwg/html#10216 for rationale. Co-authored-by: Jeffrey Yasskin <jyasskin@gmail.com>
Co-authored-by: Kjetil Kjernsmo <kjetil@kjernsmo.net>
This is based on @TallTed's suggestion at https://github.com/solid/solid-wg-charter/pull/69/files#r1523947482 but clarify that it is the on the WG to decide whether an input is relevant or not.
<p> | ||
The Solid Protocol may include protocol details for integration with identity layers and mechanisms; access management and data integrity; notifications about resource changes; and, authorization mechanisms. | ||
<p class=new> | ||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merged directly to this PR, without time to review
Too many "it(s)" with indeterminate antecedents.
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. |
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.