README.md some more comments

[bourgeoa]

@theRealImy After this PR https://github.com/solid/solidos/pull/101 there is some open pending issues from @NoelDeMartin

I've read the intro and fixed some typos, here's a couple more comments I have:

• The events page is mentioned a couple of times, which is fine to check out previous events, but for staying up to date with upcoming events I think it's better to suggest subscribing to the This Month in Solid newsletter. Maybe we could just mention both?
• When the specification is mentioned, the linked repository is https://github.com/solid/solid-spec/. But I think it should be https://github.com/solid/specification/ instead, right?
• In the list of tools, it mentions "lint" and points to the wikipedia article. Wouldn't it be better to mention ESLint directly?
• There is one part that says "a new one over at ???". I think we should either add the actual link, if we already have it, or remove this until we do. We could open a PR to track this update on the README or something else, but I don't think we should have this type of placeholders live.

1. @NoelDeMartin you raise a very good question with https://github.com/solid/solid-spec/ compared to https://github.com/solid/specification/. Both should exist and https://github.com/solid/specification/ is quoted in first paragraph of https://github.com/solid/solid-spec. The latter is much broader and should be revised to be something like solid implementation guidelines

2. I also propose to delete entirely the last header that is a repetition of a prior header with exactly the same heading https://github.com/solid/solidos#if-you-are-looking-for-something-else-let-us-try-and-guide-you

[timea-solid]

I asked Sarven about the correct specification link and he said "Ignore solid-spec. That's prior work/documentation.. Refer to solid/specification for the repo and use https://solidproject.org/TR/protocol for the spec (latest published)." Fixed with last commit on PR. Great feedback!

[bourgeoa]

I do not agree with Sarven for at least 3 reasons :

• the text is nearly readable and understandable by any non specialist. This is not the case for specification like https://solidproject.org/TR/protocol
• the text includes a default implementation of a pod's organisational concepts like public, private, inbox, profile ...
• on top the text builds a new fonctionality the extended profile for implementing a follow your nose approach

The last 2 points are not specifications but implementation of organisational concepts. This implementation is used by SolidOS.

The only thing wrong in this text is the name. It is not a specification but offer a default how-to organize a pod and implement a follow your nose approach.

By default NSS and SolidOS uses this default approach.

I am not sure there is anything wrong (?) in the content.

[jeff-zucker]

There is a committee (@VirginiaBalseiro , @theRealImy, and me) who are working on the webid profile document with intention of adding it to the TR section of the website to standardize the implementation details of the discovery process. So there will be a new version of that document and it will live with the other finished specs when it is done. Sarven agrees on including a revised webid document in the spec. I am totally in agreement with Sarven that we should NOT be pointing at the github spec repos. I find all of those other repos very confusing and misleading. For example they still talk about TLS. Additionally the old webid document is missing some key security factors and omits important details which have occurred since it was written (oidc:issuer and pim:storage are both missing, for example).

There should be documents describing the specs that are written for non-specialists. But those should be clearly differentiated from the specifications. The things in the old repo are not specifications, they are drafts - some in the pipeline and some long outdated. The fact that they have the label "specifcation" is very misleading and I do not believe we should continue misleading by pointing to them.

[jeff-zucker]

Also, if people believe that the outdated github repos are where the specs should be discussed, their comments will probably be lost since the discussions are happening in the panels relative to the panel docs and new proposals, not relative to the outdated specs.

[timea-solid]

I was not aware of the complicated situation, it is the first time I am in a specification drafting environment. @jeff-zucker @bourgeoa do I understand correctly: we should just simply delete that bullet point (referring to specs or whatever) entirely until there is better human-readable material?

[bourgeoa]

@theRealImy You are right drafting specification make thinks difficult. The first solid/solid-spec is more NSS spec. The actual solid/TR/protocol process is trying to build a first 0.9 version of a much more W3C solid recommendation. The 0.9 version should be compatible with NSS. It is a very lengthy process that can take years.

My disagreement with @jeff-zucker is very minor. I think that until something new is available the previous version should be accessible to users, with comments that it can be partially outdated.

The project you are in with @jeff-zucker shall take time and may not cover all the purpose of the solid/solid-spec discovery paper.

As a conclusion I would keep both with comments :

• TR/protocol as work in progress
• NSS solid/solid-spec discovery paper being partially outdated

[timea-solid]

So how about this wording: "- check out the in-progress Solid specification and in-progress Solid specification repo. Find the previous specifications, now outdated but still in use if you work with NSS: https://github.com/solid/solid-spec."

[bourgeoa]

For me it is ok.

[jeff-zucker]

LGTM

[timea-solid]

Thank you for the help. Change is committed on the linked PR: https://github.com/solid/solidos/pull/103