SV_MEETING_TITLE -- 11 Jul 2019

<RubenVerborgh> Anyone else trouble joining the (grrr) zoom?

<RubenVerborgh> never mind, on there

<csarven> THoguht the meeting was in an hour?

<RubenVerborgh> 1000 CEST, that's now

<Mitzi> https://zoom.us/j/121552099

<csarven> My eye interpreted the 11 in "20190711_1000CEST"

<csarven> This is why professionals use calendars and Sarven uses his eyes.

<Mitzi> we're still warming up with intros, come join if you're available

Mitzi describes how to use irc

Ruben's agenda item:

what we do in Solid is making sure that clients and servers can communicate with each other

<Mitzi> https://solid.github.io/specification/ and https://github.com/solid/specification/issues/5

it's very important that we have the right agreements in the middle

Solid is not reinventing the web from scratch

we're building on top of http, url, ldp, oidc

our spec should describe how those specs should be used together

up until now, spec was informal, more like a wiki

the gap between that and what we need is three things:

it should be clear

it should be unambiguous

so that two implementations will work together, even if we never talk other than both read the same spec

unfortunately it's sometimes self-contradictory and vague

almost everywhere, there are so many choices that if 10 people read the spec, then you get 5 different interpretations

to improve the spec we need processes, which Mitzi will talk about later

the other thing we need is a good structure

<RubenVerborgh> https://solid.github.io/specification/

a fresh repository to whcih it's easy to maek contributions

<RubenVerborgh> http://github.com/solid/specification/

it's the final document, rendered every time someone commits to master

and the github source of that &

the spec is about taking the rough consensus and translating it into an unambiguous text

biut there are some parts that have never been written down yet

Max:

now may be the time to say

as a totally fresh outsider

how i plan to use the spec

what seems important to us

my background: basically, three projects

company owner, consultant

1. yourdata (data modeling for real estate, using rdf, solid as the backend server). especially interested in LDN, realtime interaction

2. matrix-im protocol

very close to solid in terms of how data is exchanged, and identity. specially interested in privacy

have done quite a bit of spec work there

experience with reading a spec, implementing it, seeing where it breaks down

3. because matrix doesn't deal well with privacy, we forked the spec

and i'm writing that spec from scratch

i've been looking at Solid and linked data for a while now and looking at how to integrate it

the big question is identity there

i'm covering all the areas a bit, but this is an example of how we want to use linked data and solid

i would love to see the spec and see the new exciting ways of using it

Ruben: one smal correction

'also writing from scratch' -> we are only rewriting the document, not the spirit

Max: that's als what i do

Mitzi: how to come to consensus

that PR is there to review in the culture repo

what Ruben is putting forward is the beginning step

it can evolve and change

but we need to start somewhere

Ruben, can you describe the overview of spec structure you propose?

Ruben: this is a democracy, not a dictatorship

in good faith, i made a proposal on how to start

we're not going to impose

people who will be working on these documents are not decision makers, only translators

and sometimes we need to make textual changes, but they go to pull requests we can review

that's the basis

<RubenVerborgh> Looking at https://solid.github.io/specification/

i try to translate what we want in a document structure

the first thing of note is

'the solid specification' does not exist

the name of these documetns can still change

there's one base document, which explains how they link together

we're using these specs, in these ways

for instance, we're marking some optional things from component specs as required for Solid

<RubenVerborgh> https://solid.github.io/specification/wac/

rather than defining for instance WAC in the main spec, we put it into a separate doc

because WAC can perfectly be reused outside Solid, just like LDP

and it also makes it easy to collaborate

if the WAC spec does not tightly depend on the CORS spec, for instance

orthogonality and independent evolution

but in a single repo, because we see issues that are cross-cutting

so that's why we propose documents in a single repo

<RubenVerborgh> michielbdejongh: there currently is a main spec and component spec

<RubenVerborgh> Tim's concern is that we are breaking URLs

<RubenVerborgh> URLs should stay the same

<RubenVerborgh> is there are reason?

<RubenVerborgh> ack

reason we don't stay at the same URLs is that we want gh-pages URLs instead of gh repo URLs

so that we can use formatting

Mitzi: the new places should be properly redirected to

Sarven: that's a good concern, we could even, starting now, commit to some sort of persistent URI

which can then of course redirect

but in the future it might not be on github

so it would be good to have a persistent URI that's independent of github

in context of the community group and what we intend these specs to be

the lifetime of the things we're doing, it's not a spec from the point of view of for instance W3C, so eventually we'll have to hand it off to W3C or similar

maybe IETF

and usually they want - we can have multiple identifiers

as long as we consider the current URI as a temporary URI, that's not a problem

so we're not going to commit to the new github URIs longer-term

Mitzi: the conversation about what standards body to use -

there is a process from W3C CG to W3C WG but that's quite heavy

so that's a conversation we'll probabhly have to have at some point when we're more confident our draft version is more robust

Mitzi: who's going to be responsible for making the links go to the new repo?

<RubenVerborgh> https://github.com/solid/solid-spec/

Sarven: i want to ask which repo were you referring to

Mitzi: the three existing spec repos, under github.com/solid

<RubenVerborgh> https://github.com/solid/webid-oidc-spec

Sarven: we could ,with Tim's blessing, even now publish these under w3.org

even if it's the current state, that's fine

even the vocabularies

which are not officially recognized beyond people experimenting with them

they will remain there when they bcome more substantial/mature

w3c pledges this

Mitzi: we do have w3.org/solid, it's empty

the hesitation is whether we actually want to be in W3C

the main concern is whether the voice of browsers can influence the content

for now, let's get to a version 1 with everything in one place

Sarven: if it's not a W3C product or WG, the members won't say anything

maybe we can have a separate call about persistent URLs

Ruben: I'm unassigning myself from that task until we discuss it more
... the structure and the decisions we made

<RubenVerborgh> https://solid.github.io/specification/

the main document ^

three or four broad sections

authenticated resource access (server and client)

optional integrations

layers of compatibility

security considerations

there's no specification for webid yet, but it will be quite short, so can be inline

two ways for authenticating, webid-oidc and webid-tls

those other specs will be docs in this repo

same for WAC

2.4 on CORS, existing spec

section 3 about clients

interoperability between apps and data models

useful principles if you want to implement a client

see Ruben's blog post about solid apps should be coded against data shapes and footprints

3.3 about data shape guidance

in the short term, what vocabs will be used for people, photos, etc

3.4 notifications

LDN, as well as real-time / websockets

needs to be detailed

Max: where is the boundary in terms of server vs client, the exchange and the data modeling

the whole linked data part is how you deal with data and represent it, right? and Solid is the framework of how you use it?

Ruben: section 2 covers the protocol interop, client-server

but if you only that, then you don't have interop yet, because the data on the pod might look different from what the app expects

section 3, longer term plan

Max: that is a big relief

there was clearly something like that missing

Ruben: we need protocol-level as well as data-level interop

Sarven: it's a more advanced way on a broader scale

you can get interop with linked data out of the box

data can self-describe

if i publish something using your own terms, then there might be an equivalence relation to other terms that apps might wokr out bout that's not good enough

we need some massaging

Ruben: those are the two mandatory parts

section 4 is optional

e.g. an interface for pod- and user management

this is new teritory

those will be separate docs

query interfaces

such as TPF

this is new, there are existing specs

prototypes mainly so far

there has been a call for versioning

and negotiating [...]

we can link to existing spec

verifiable credentials

URLs that give you specific access

security considerations

specific section

might become non-normative as they may not be technical

that wraps up the structure

it's one repository

every change from this point onwards is a PR

we should nto commit to master directly

<RubenVerborgh> michielbdejong: we could decide that Ruben/Sarven/Kjetil are expert panel

<RubenVerborgh> we could elect you to be that expert panel

<RubenVerborgh> there are other proposed panels

<RubenVerborgh> the client/client (shapes) spec

<RubenVerborgh> and other topics that are not in the current TOC

<RubenVerborgh> so it would be in theory reshuffling what we have, and adding in

<RubenVerborgh> the decision to add VC is a decision by another panel

<RubenVerborgh> mandate is only the TOC

Mitzi: it's good if we make explicit who works on what

<RubenVerborgh> michielbdejong: mandate also includes adding in text

Mitzi: any final comments?

<Mitzi> https://github.com/solid/information/blob/master/solid-vision.md

if the process doesn't change then we now decided that Ruben, Sarven and Kjetil (if he wants to) will from now on be in charge of the spec structure

their mandate will not be to add new things to the spec, but to improve the structure, and put the existing bits of text into this new structure

Mitzi: Dan and I have been working on a different leve

Solid has to be representative of our common vision

Dan Wilkinson: just quickly,

i'm still very new to this

and probably 95% of what you just talked about went fairly high over my head

but i think the key is, regardless of how Solid is interpreted or communicated, it's absolutely based in the reality of wha thte technical spec delivers

so what we communnicate should be true regarding waht the technical spec delivers

what solid is going to do

effectively drives what we tell the rest of the world

i've worked in branding, advertising and marketing

we should tell a clear and confident story about what we wan tSolid to do in the future

that's crucial to get momentum

so it's about the realities but also about that vision for the future

the bigger movement

what is Solid helping to make happen

vision statements

guide everyone in terms of where ther

y getting to

even if we can't deliver them right now, they're guiding stars

i meet lots of people who i talk to and there's a huge amount of excitement about what this is trying to do

people really think it's something that needs to be addressed

even the tech community

how do you communicate the core role that Solid is playing

and what it can and can't do

particularly on the privacy front

what it might solve and what it can do

any brand and organization

if you can define yourself in an incredibly clear way

that breads confidence in what you're trying to do

that's what we try and look to develop here

Sarven: i totally agree and would add

alignment with the existing initiatives

the stuff we're doing with Solid is not coming out of nowhere

it's emerging since the beginning of the web

standards

people building appliications

communities

there's a common agreement and understanding about where we want the web to be

how that helps us change society

we should align ourselves with those things and not present Solid as something new

we can talk about it at the technical level as well

how do we make it happen

it's good to say that we can randomly pick a community on the web right now that will probably agree on similar visions

there's interop at that level

speak iwth other commnuities

we want to empower people, allow them to control their data

connect with others

as much as we're working on specs and building tools

it's important to connect to other communities

csarven: +1 to that! :)

Mitzi: identify the goal of Solid

the spec conversation should link to these last 10 minutes

there should not be a mismatch

fro isntance section 5

we talk about privacy

a brainstorm at the beginning of next week's call?

Ruben: if we just have a list of the goals then that's fine

calls do not lend themselves to brainstorms

Mitzi: in line with what?

the Solid vision doc that Mitzi wrote?

Ruben: let's do this in the repo instead of in calls

<RubenVerborgh> https://github.com/solid/information/blob/master/solid-vision.md

Mitzi: but i want more input for how i'm writing this

Sarven: we can edit that collectively

happy to add

Mitzi: thank you, i'm feeling out of my depth

Sarven: this can be incorporated in some eco system doc where we address the why

Mitzi: thanks, let's continue next week

<RubenVerborgh> thanks all, thanks to the scribe as well

Michiel: congrats and good luck to Ruben, Sarven and Kjetil as the first of our 10 or so expert panels

- DRAFT -

SV_MEETING_TITLE

11 Jul 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output