proving that conneg is a breaking change

[melvincarvalho]

There are two Webid Specs, WebID 1.0 and WebID 2.0.

WebID 1.0 mandates a serialization, say Turtle.

WebID 2.0 mandates conneg, with Turlte and JSON-LD

Alice has a WebID alice.ttl which has been her webid for 10 years. She uses it with all her solid Apps.

One day Apps switch to WebID 2.0 and the newer JSON-LD becomes the preferred serialization

Alice's WebID is now broken. Furthermore it's hosted on her own home page using Apache, and she has no ability to fix her webid. This breaking change, makes all of Alice's work over the last 10 years potentially broken.

QED

[webr3]

If we would relax the serialization requirements by removing Turtle, i.e. removing them altogether, how would that break the backwards compatibility?

It's probably the only viable approach, because of the issue that's being skirted: there is no versioning within implementations, code, or data.

Given a set of 15 URIs - which we assume refer to agents - it's impossible to inform a client ahead of request as to what to expect, what request to make, no way to say make a v1 or v2 request, no way to flag 7 as v1 and 8 as v2 within document data, or maintain that over time. Even considering it leads you to ridiculous approaches like webid-v1:knows and webid-v2:knows, or having a different uri per version/mediatype.

Ultimately it doesn't matter if a spec has a version or not, because there's no way to enforce, sniff, detect, implement, or even check it's a valid v1, v1.6, v2, or v14.

To be honest there are many issues being skirted. Literally the only bit of what we'll refer to as WebID 1.0 that can be used long term is use GETtable HTTP URIs. There's no ontology. There's no media type. There's no protocol. Even use client certificates over tls is a no go for scaling, as TLS termination is invariably offloaded in any scaled or cdn'd deployment of anything webby.

The only things we can specify in any detectable and useful manner are:

• use GETtable HTTP URIs
• specify the type/class of an :Agent or :Person, along with some useful properties in a vocab with domains and range set appropriately
• provide examples in multiple mediatypes (extension profiles).

Any discussion about trying to enforce an undetectable version, or fix mediatype(s) or mandate conneg are simply not enforceable, and indeed counter productive as they place an expectation that if you get turtle or json-ld document, every uri you can follow your nose to will also be available in the mediatype you received at the last hop. Even the recommendation of sticking to specific media types will most likely be invalidated by time (turtle -> json-ld -> json > not-invented-yet), and just totally ignored outside of specific communities or clusters of projects

I'd love us to focus on the three things we can actually do, totally remove the rest, then perhaps we can get to the useful and interesting bits around how to even do various styles of auth, and coding up plugins, extensions, apps, and patches to widely used projects.

[melvincarvalho]

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

Perhaps its helpful to give some background. WebID was in development for 5+ years before it got to 1.0 in 2014. Longer if you consider foaf and foaf-protocols before it.

The reason it was called 1.0 rather than 0.x was because it was considered finished, stable, and ready to use by the authors. That proved to be the case as we spent many years building Solid on top of it. The only reason it didnt become a REC was because of an arbitrary decision of LDP not to include identity in the first version. There was then an idea it could become a REC in the Solid WG.

That's why it's 1.0 and not 0.10 etc. Note Solid is still in the 0.x phase which indicates that 0.x+1 can change bits. 1.0 was an indicator of stability and completion and it has been so for 10 years.

Any new work with new authors/editors/methodology should respect that by starting at 1.1 under all scenarios. It's just far too confusing to do anything else. Minor changes could be put into a 1.1 spec and subsequently published. The main thing that I see is that JSON-LD could be put on the same footing as RDFa as a MAY. In fact RDFa should be replaced with JSON-LD IMHO. That I can see being a non-obtrusive 1.1 release.

Any major breaking changes should be 2.x, and conneg being mandated falls under that category.

The only scenario I can see where something different could apply would be if everyone, including the Solid WG had a unanimous agreement to redefine the concept in order to make it a W3C REC. But we dont have word from the Solid WG yet, so that seems premature.

Let's do proper versioning based on breaking changes, and to show respect to the authors that came before who felt, understandably, that they had made something finished and ready to use. I hope that adds some extra clarity.

[melvincarvalho]

If we would relax the serialization requirements by removing Turtle, i.e. removing them altogether, how would that break the backwards compatibility?

Timbl was very insistent on having at least one MUST. Basically it means that all clients and servers can ensure a consistent UX for the eco system.

Let's say you dropped turlte, and then one group wanted RDF/XML another n3. End users would not know what was happening.

[jacoscaz]

/chair hat on

There are a few things that I would kindly ask everyone to stop and think about before continuing this conversation.

Quoting from this comment:

All existing WebID providers (Inrupt, Use.ID, OpenLink, solidweb.me, redpencil.io, inrupt.net, solidcommunity.net ...) already provide Turtle+JSON-LD through conneg.

Quoting from this comment:

I've search through the 6p of NPM packages that use the term "WebID" in their description, and looked into their actual code. Here are the numbers:

• Only 7 packages actually looked up a WebID Document.
• Only 2 packages them are popular (>10 downloads/week):
  • @inrupt/solid-client-js (9,433): requests & parses Turtle (though caller code can pass in another parser).
  • @solid/access-token-verifier(395): requests & parses Turtle
• 71.4% (5/7) only request & parse Turtle
• Only 2 hardly used packages can parse something else:
  • webid-pubkey-credentials-module(3): requests unspecified & parses any RDF format
  • node-webid (0): requests Turtle or JSON-LD & parses any RDF format
• webid-provider-tests (of the Solid CGs official test suite): requests & parses Turtle

Again, in as far as these numbers tell us anything, they clearly indicate the predominant presence of Turtle as expected WebID format, not only in absolute numbers, but especially through the strong reliance on a limited set of libraries that use Turtle.

Unless anyone can refute the above, the only practical breaking change that would be introduced by a MUST on Turtle and JSON-LD for publishers would be to make statically hosted WebID Profile Documents in the form of Turtle .ttl files non-compliant when requested by clients indicating support for JSON-LD alone via the Accept header.

This is, indeed, a breaking change, albeit a minor one if we weigh it against the number of occurrences of this particular hosting scenario. Nonetheless, it deserves to be called for what it is - breaking. If we were dealing with a WG aiming to push forward with the next version of a published spec, this would amply justify a version increase.

However, as the 2014 ED itself reminds us, there is no such a thing as WebID 1.0:

This document is produced from work by the W3C WebID Community Group. This is an internal draft document and may not even end up being officially published. It may also be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. The source code for this document is available at the following URI: https://dvcs.w3.org/hg/WebID

In fact, any WG that adopted our drafts would be in charge of producing exactly that, the first published, official version of the WebID spec: Web Identity and Discovery (WebID) 1.0 . Adding a version number other than 1.0 to our drafts makes absolutely no sense, if only for the fact that the first official version of the spec would see that number decrease back to 1.0.

Nonetheless, given that we are dealing with a breaking change, we do need to provide some way to easily discriminate the working draft from the 2014 ED. Luckily enough, this is how the 2014 ED looks, both in this repo and in the old incubator pages:

Though it has been around for a long time, any adopter of the WebID 2014 ED who has actually taken the time to even simply glance at the spec from a distance is already aware of its nature as an ED because the document itself makes that crystal clear.

There is no reason to hold back on a breaking change, if there is consensus behind it, as long as we produce a document that can be easily told apart from the 2014 ED. As the screenshot above demonstrates, that's more than easily achieved by simply changing the date.

This is how I'm going to move forward, as chair. If any of you were to find it unpalatable, I invite you to a) refute any of the above in a clear, demonstrable, replicable, grounded manner and b) ask me to resign. I serve the group and, if the group deems it so, I'm happy to step down and let someone else carry things forward.

[melvincarvalho]

This is, indeed, a breaking change,

Thank you very much for confirming this. That was the purpose of the issue.

Also thank you for considering all the nuanced viewpoints and reaching that conclusion. IMHO an example of good chairing.

I am saying very clearly that I do not want breaking changes to the spec that we have, no matter how slight they are considered by some, there is clearly a spectrum of views on how big a change it is. I personally feel it's the biggest breaking suggestion we've had in years.

There is no reason to hold back on a breaking change

I disagree on this completely. You do NOT have consensus to introduce a breaking change.

This is how I'm going to move forward, as chair.

You cannot railroad breaking changes through to a mature, in use, 10 year stable spec, which has a eco systems built up around it, without full consensus.

I simply ask you to focus on items with consensus. This is something you have always done to date. I still have confidence you will continue to do so.

[melvincarvalho]

As the screenshot above demonstrates, that's more than easily achieved by simply changing the date.

You honestly lost me completely wtth this.

It clearly says WebID 1.0 on your own diagram. It was considered finished, complete and ready for production by the authors. Changing the date to shoe-horn in breaking changes is a non-starter.

[melvincarvalho]

This issue can now be closed, I think we've all expressed ourselves.

We can move forward having proved, and with a group consensus that introducing JSON-LD=MUST and/or conneg=MUST is a breaking change.

It goes without saying that breaking changes are a high, or perhaps the highest, level of controversial changes a group can have.

How we move forward I think is an orthogonal conversation.

So I suggest closing in this in a bit, unless someone wants to try and argue that it's not a breaking change. Else we can move forward with a shared understanding which I think will enable progress.

[jacoscaz]

You cannot railroad breaking changes through to a mature, in use, 10 year stable spec, which has a eco systems built up around it, without full consensus.

@melvincarvalho at this point I'm not going to spend any further time on arguing about whether I'm railroading anything or not. Fortunately, everything we do is on record, for everyone to see. You have the right to draw your own conclusions, of course, and I respect that. We obviously disagree on many things, which is also absolutely fine, but I do not have it in myself to continue this manner of interaction as I'm aware that I would become more adversarial than anyone ought to be in their professional (and, IMHO, personal) conduct.

I'm going to move forward following the principles that I've laid out in https://github.com/w3c/WebID/issues/58#issuecomment-1925809369 unless someone refutes them in a clear, demonstrable, replicable, grounded manner and/or the group asks me to step down.

[webr3]

However, as the 2014 ED itself reminds us, there is no such a thing as WebID 1.0

I'd point back to #17 here.

Is there a document called WebID that says it's a specification - yes.

Is WebID itself, or a WebID specified by that document: no.

The document specifies one thing, a get that responds with turtle. That is not a specification of WebID.

Taking this document, and making a new one that still fails to specify WebID, but now says get turtle or json-ld is totally valueless. WebID is still entirely unspecified in any way, anywhere, in any draft.

[melvincarvalho]

@melvincarvalho at this point I'm not going to spend any further time on arguing about whether I'm railroading anything or not. Fortunately, everything we do is on record, for everyone to see. You have the right to draw your own conclusions, of course, and I respect that. We obviously disagree on many things, which is also absolutely fine, but I do not have it in myself to continue this manner of interaction as I'm aware that I would become more adversarial than anyone ought to be in their professional (and, IMHO, personal) conduct.

I'm going to move forward following the principles that I've laid out in #58 (comment) unless someone refutes them in a clear, demonstrable, replicable, grounded manner and/or the group asks me to step down.

• You do not have consensus for that. I would appreciate if you would at least acknowledge that.

Counter proposal. Why not do things that went through the hard multi-month, multi year process of gaining consensus such as the "superspec", which is a shared, serialization-agnostic, understanding of what WebID is, and leads extension profiles, which allow everyone to work?

• You do not have consensus for breaking changes. I would appreciate if you would at least acknowledge that.

Counter proposal. Why not do things that are non-breaking, or completely new work?

• You do not have consensus to reuse the existing 1.0 version number for your newly edited work. I would appreciate if you would at least acknowledge that.

Counter proposal: bump the version number so that ALL can see the difference. Why cant this be done? The authors/editors of the new spec didnt write WebID 1.0, what claim do they have to it? New work should be unambiguously be made clear as new work, and changing a date is not enough. When did you ever look at a spec and say, "ah the date is different, that's significant"?

• You have yet to receive consensus from future Solid WG for your changes. I would appreciate if you would at least acknowledge that.

Counter proposal: why not be patient and wait for Solid WG to start up, and engage with them, ask them what they want. See if they want WebID to be a REC? Ask them what shape they would like it to be. Find out their needs. Why does it have to be so rushed through (you perhaps dont like my use of the word railroading, so i could withdraw it, and say "rushed", is that better?). Solid WG is predicted to start up early this year. This all seems rushed.

How you proceed is up to you. But I will say that you have a close to perfect track record so far. I can only ask you take consensus into account with your decisions, and Im optimistic that you will.

I would urge you to focus on the items where you do have consensus. IMHO you've done a fantastic job so far. You've just pivoted from the tricky task of making WebID well-defined, modular and useful, to the impossible task of trying to gain the most difficult consensus that has not been achieved in years, and proposing the biggest change. This is no failing of yours, I dont think anyone could have managed such a difficult task, because there's an inherent impossibility to find serializations that please everyone.

I'd encourage you to take the low hanging fruit.

EDIT: In any case, I wish you the best of luck, whatever choices you make. Also tried to make the tone a bit more neutral+constructive.

[kidehen]

Sure they would. Linked Data is just another name for the Semantic Web. It's about having machine and human readable documents on the web, including with hyperlinks.

Linked Data isn't another name for the Semantic Web.

Linked Data is simply a principled approach to structured data representation that CAN manifest a Semantic Web. The rules are simple:

1. Name anything of interest using an HTTP URI.
2. Describe said item of interest using RDF sentences/statements -- where subjects and predicates are denoted by an HTTP URI, while objects are denoted by an HTTP URI or literals (which may be typed or untyped).

A Semantic Web is an entity relationship graph comprising machine-readable (or computable) entity relationship type semantics -- informed by an Ontology.

Thus, you can create a basic "Web of Data" using Linked Data principles without links that denote terms in an Ontology (the key to machine-readable entity relationship type semantics).

[kidehen]

• provide examples in multiple mediatypes (extension profiles).

Examples can be provided in the specs too, without the need for profiles. The issue right now is that the old spec conflates too many things, for all the wrong reasons.

+1 for you comments, but noting the view expressed above.

[webr3]

Examples can be provided in the specs too, without the need for profiles.

Agree, though there is perhaps some merit in being able to factor out media-type specific nuances to isolated documents, and allow new ones to be organically created independently.

The issue right now is that the old spec conflates too many things, for all the wrong reasons.

Couldn't agree more, it's probably clear that personally I'd just leave it where it is, part of history from a different generation and clean slate write something for now. Any consideration to b.c. should be with software that currently exists which has high usage and technical reasons why it cannot be modified easily. There's no point inventing blocks and assuming they are real when perhaps they exist in the realms of thought only.

[melvincarvalho]

Ive suggested this as a possible direction to take.

https://lists.w3.org/Archives/Public/public-webid/2024Feb/0002.html

[melvincarvalho]

This is how I'm going to move forward, as chair. If any of you were to find it unpalatable, I invite you to a) refute any of the above in a clear, demonstrable, replicable, grounded manner and b) ask me to resign. I serve the group and, if the group deems it so, I'm happy to step down and let someone else carry things forward.

Your leadership as chair has been nothing short of remarkable, propelling us to unprecedented achievements this quarter. Your ability to discern and address legitimate concerns has been a key factor in our success.

However, I would much rather suggest slowing down or pausing, rather than anything more drastic. In order to allow the soon-to-form Solid WG to shape, and they can inform us with vital new information. Taking a well-deserved break might be far preferable to resigning or prematurely tackling highly controversial items. The problems then start to fix themselves in Q2 of 2024 when there will be clarity, where before there was none.

The progress we've made under your guidance is undeniable, and what is needed is a serialization and implementation neutral way to define and specify WebID. Conversely, without that shared understanding of what a WebID is, we stand almost no chance of creating a consensus based specification. So the only thing needed here is to do things in the right order (namely defining and specifying WebID first, then picking serializations), and if in doubt, to slow down. I appreciate that is easier said than done, and that you take pride in your work. But let's build on success in a low-risk way, rather than taking the (unnecessary) high risk path to premature failure.

EDIT: text clarity improved after feedback

[TallTed]

slowing down or pausing

Indeed. 65 comments on one new issue over a weekend. Plus at least two significant email threads. And other (long!) issue discussions besides.

It's great that some people are able to devote all their waking time to such. I am not one of those people.

Slowing down, giving time for readers to consider and respond to comments/posts, would not only be a good idea, I think it a necessity. Else, this may well turn into a 5-ish person round-robin, the output of which may not find general consensus among those in the CG (or eventual WG), never mind eventual team review for transition to REC.

[melvincarvalho]

Discussions are fine, as they refine understanding. For example it was unclear before this issue, that proposed changes to add JSON-LD and conneg as a MUST were a breaking change.

This issue has established that the proposed changes are indeed a breaking change

What should be slowed or paused is breaking changes being applied to WebID. I have advocated for a freeze for some time, until we can, as a group, come up with a serialization and implementation neutral way to define and specify WebID. Something that we as a group should have done years ago.

If that can be achieved in Q1 of 2023, or even Q2 (there is no rush). It would be a valuable documentation that lives on its own merits. Then, and only then, is it logical to discuss serialization preferences.

[melvincarvalho]

It's great that some people are able to devote all their waking time to such.

@TallTed please, be respectful. Your tone is inappropriate. Passive aggressive micro-aggressions add nothing constructive to the conversation.

[melvincarvalho]

Really, @melvincarvalho? This is not an issue. @jacoscaz, I suggest moving this to Discussions, which we specifically opened for things like this.

I dont mind at this point if this is converted to a discussion, or even better, closed (as there are some external links to it), having established the main premise to reasonable satisfaction.

[jacoscaz]

/chair hat on

Else, this may well turn into a 5-ish person round-robin, the output of which may not find general consensus among those in the CG (or eventual WG), never mind eventual team review for transition to REC.

@TallTed and all: we do have a process in place that guarantees review times of up to 4 weeks for breaking changes and I remain steadfast in my quest for unanimity first and, if that cannot be achieved, as large a consensus as we can muster. While conversation can happen in bursts and evolve quickly, this doesn't automatically extend to how changes are made.

There's really no risk of this happening as long as we stick to the process we have in place. While I do share a certain frustration with how parts of the conversation are being brought forward, at the present moment there's no risk of anything being decided against general consensus.

[melvincarvalho]

@TallTed and all: we do have a process in place that guarantees review times of up to 4 weeks for breaking changes and I remain steadfast in my quest for unanimity first and, if that cannot be achieved, as large a consensus as we can muster. While conversation can happen in bursts and evolve quickly, this doesn't automatically extend to how changes are made.

There's really no risk of this happening as long as we stick to the process we have in place. While I do share a certain frustration with how parts of the conversation are being brought forward, at the present moment there's no risk of anything being decided against general consensus.

In response to your message, I'd like to express my concerns with utmost respect but with necessary candor. The current approach to implementing substantial changes in a well-established, decade-old project raises significant apprehensions. Introducing major modifications without a more inclusive timeline for feedback disregards the extensive ecosystems and toolings that have matured over the years. Such a brief window for feedback, especially when it risks overlooking substantial objections, seems incongruous with the collaborative spirit and technical stability we've cherished.

Moreover, the decision to not revise the version number amidst these changes is perplexing. Maintaining the version as 1.0, despite fundamental alterations, not only confuses but also undermines the integrity of the project's evolution.

Crucially, the prioritization of this fork over the foundational task of defining WebID in a serialization-neutral manner contradicts the collective wisdom of the group. This leapfrogs the essential step of establishing a common understanding of WebID, crucial for ensuring compatibility and coherence across the board.

Additionally, the timing of these changes is particularly troubling. Forcing this transition in the narrow timeframe before the inception of the Solid WG deprives a significant stakeholder of their rightful input, potentially alienating a key segment of our community.

While change is inevitable and often necessary, the manner and sequence in which it is executed bear profound implications. The convergence of these concerns – the haste of implementation, disregard for versioning semantics, inversion of priority over serialization neutrality, and the ill-timed scheduling – collectively signify a departure from the principles of inclusivity, foresight, and respect for the community's legacy and future.

It is with a sense of responsibility towards the project's long-term health and community cohesion that I voice these objections. In the spirit of constructive dialogue and shared commitment to the project's success, I urge a reconsideration of the approach to ensure that it aligns with our collective aspirations and principles.

[jacoscaz]

/chair hat on

@melvincarvalho I don't like to ignore people but I can't keep addressing the same points ad infinitum. I will do so once again, here, and then stop answering to any further mention of these specific issues from you.

the haste of implementation

So far, the only actual changes I've merged in since I became chair are:

1. Formalizing our process and making it explicit.
2. Conversion to BikeShed.
3. Intended audience.

Other than this, the only thing I've done is trying to foster and locate consensus (see #37). I can't see how any of this classifies as haste (or implementation!).

If you believe that 4 weeks are not enough for major PRs to be adequately discussed, why don't you adopt a more proactive stance and propose a change to our process?

disregard for versioning semantics

I've already made my point in https://github.com/w3c/WebID/issues/58#issuecomment-1925809369 . The 2014 ED states very clearly its own nature as an ED. You disagree, and I respect that, but I'm not going to change my mind just because you keep making these accusations.

inversion of priority over serialization neutrality

At some point you will have to accept that not everyone believes in serialization neutrality. I can't do much more than quote a couple of recent posts to make you understand that, as chair, I can't just go with what you (or I, for that matter) want.

• https://github.com/w3c/WebID/issues/3#issuecomment-1879750583
• https://github.com/w3c/WebID/issues/17#issuecomment-1877196126

Forcing this transition in the narrow timeframe before the inception of the Solid WG deprives a significant stakeholder of their rightful input

Solid people are welcome to join in the conversation here. Nobody is blocking them from doing so. In fact, I've been actively trying to reach out to them but, if I had to guess, they do not believe participation in this group to be a productive endeavor - and that is on all of us. I would like to prove them wrong and have them join the conversation once again but I can't do that on my own.

If you find any of my answers to be unacceptable, I beg you to please make the case for my resignation rather than continuing this manner of interaction. I understand disagreement and I would not think any less of you if you were to do so. I've said this many times: I'm happy to step down if the group would rather have someone else.

[melvincarvalho]

I am asking you to prioritize things in the right order.

1. define and specify webid, then select serialzations -- success
2. select serializations + forking before webid is defined -- split group, and both halves fail

Its simply an ordering problem.

Build the house then build the bathroom. Dont build the bathroom then build the house.

The failure here is to understand that serializations can be selected after WebID is defined.

Just as SPARQL can be defined then used with any number of serializations. But SPARQL cant be used with any serializations, before it is specified.

I need you to acknowledge the logic of the two step approach being consistent with everyone's needs. Arguing that Turtle=MUST PRECLUDES defining defining WebID just is not a serious argument. Defining and specifying WebID ENABLES the serialization conversation.

We just have to avoid putting the cart before the horse. Specify WebID and everything else follows.

[melvincarvalho]

What is the URL

@woutermont I'll note you've not yet provided a URL for the implementation that you outlined. Does it still exist?

[melvincarvalho]

Let me add the mail list comments from Ruben Taelman:

https://lists.w3.org/Archives/Public/public-webid/2024Feb/0047.html

I just want to briefly chime in and say that the “MUST on Turtle and JSON-LD on publishers” may represent consensus among the loudest and most present voices in this CG, but it may not necessarily represent what less vocal people may be looking for.

But I strongly agree with Martynas’ comment on that WebID should be orthogonal to what RDF serialization is used. WebID and RDF serialzation apply to different locations when observed in a layered structure. It’s like expecting HTTP to suddenly start requiring at least WiFi 802.11ac to be used, these are orthogonal things.

emphasis mine.

[melvincarvalho]

This issue can now be closed, having proved sufficiently, that mandating conneg (e.g. via JSON-LD AND Turtle = MUST), is a breaking-change.

[csarven]

Solid people are welcome to join in the conversation here. Nobody is blocking them from doing so. In fact, I've been actively trying to reach out to them but, if I had to guess, they do not believe participation in this group to be a productive endeavor - and that is on all of us. I would like to prove them wrong and have them join the conversation once again but I can't do that on my own.

You're severely mistaken.

All, if not, vast majority (perhaps except you) of the active/substantial contributors here are literally involved in Solid and in general have been driving the RWW space forward.

I for one helped to get the work continue in this repository so that the stalled work in the WebID CG can continue. You can read a brief background at https://github.com/w3c/WebID/issues/5#issue-1153260476 . I've also put in effort to work to continue even further in a W3C Recommendation track through the Solid WG charter proposal ( see proposal: https://github.com/solid/solid-wg-charter/issues/39#issue-1741064792 https://github.com/solid/solid-wg-charter/issues/39#issuecomment-1580886272 ) and efforts to unify communities. I've created/connected various issues/PRs, did all the open "grunt" editorial work (when no one even approached it for years.)

And I can refer to numerous other contributions from "Solid people" if that doesn't suffice. Your assertions are not only significantly mistaken, but I find it impolite. It is not you that needs to welcome "Solid people". "Solid people" have been active participants in this community long before your arrival, and if anyhting, it is they who welcomed you.

Start by speaking for yourself ( see WebID CG communication guidelines borrowed from Solid CG's contribution guidelines) instead of chalking up a whole set of participants as to what they think or don't about the current state of affairs.

Consider reading your statements again after perhaps considering the possibility that you may be in fact ignoring or downplaying recommendations that are spelled out from the start; clearly demonstrating "NIH"; anything and everything from chairing to editing..

[melvincarvalho]

However, I would much rather suggest slowing down or pausing, rather than anything more drastic. In order to allow the soon-to-form Solid WG to shape, and they can inform us with vital new information.

Wishing to address this. We have new information, the Solid WG is delayed and changing to the PUMPKIN WG. That means that the original consideration of waiting for clarity on that. We now have that clarity. We need not be too heavily held up by PUMPKIN WG as it is unclear that they are near forming a WG, let alone taking WebID to REC.

@melvincarvalho to clarify, would changing the title of the working draft https://w3c.github.io/WebID/spec/identity/index.html to Web Identity and Discovery 1.1 cause you to withdraw your strong objection to conneg?

For the record, yes I think I could live with that, at this point. Removing blockers to new work.

[melvincarvalho]

And I can refer to numerous other contributions from "Solid people" if that doesn't suffice. Your assertions are not only significantly mistaken, but I find it impolite. It is not you that needs to welcome "Solid people". "Solid people" have been active participants in this community long before your arrival, and if anyhting, it is they who welcomed you.

@csarven please be respectful, and operate in good faith. The tone here is not the best. @jacoscaz has worked very hard to be inclusive.

Consider reading your statements again after perhaps considering the possibility that you may be in fact ignoring or downplaying recommendations that are spelled out from the start; clearly demonstrating "NIH"; anything and everything from chairing to editing..

This is off-topic, and inappropriate.

You're severely mistaken.

All, if not, vast majority (perhaps except you) of the active/substantial contributors here are literally involved in Solid and in general have been driving the RWW space forward.

Again tone could be better. Obviously there's quite an overlap with RWW, WebID and Solid (now PUMPKIN). IMHO your ambition to be chair of the Solid WG was one more issue that it needed to handle. You could achieve everything you wanted as an IE rather than a chair. There wasnt a need to push for objections on the Solid WG based on chairs, when there were two perfectly good ones. Let's put the animosity to one side and work together to make a better web.