<scribe> Agenda:

<michielbdejong> scribe: jackson

Michiel presenting two options: spec is unclear. How to send chat invitations

Dan: Solid brand identity

Mitzi: Update code of conduct

No other points to add to the adjenda

Michiel: SPec is unclear:

He linked to a github issue

https://github.com/solid/solid-spec/issues/174

When an app gets a webid oidc token it must be for a specific origin

When there is an origin header it checks an app is allowed

WAC allowed-headers

Right now it's not in the spec but it's implemented

So, let's not keep it in the spec because it's inefficient to implement

Tim: We put WAC-allowed headers in for a reason

It tells the data browser to give read view or read-write view

It allows the UI to make public links to it

<elf-pavlik> jackson: we use redirect IRI to identify client now, don't pay attention to Origin header for that any more

There's a lot of conversation and origin headers and wac allowed headers so that means that these are unclear things

We don't actually have a working implementation of websockets

So let's build that first

Deleting on Empty containers: We're agreed that a container must be empty before it's deleted

Trailing slashes in ACL docs: Recommended to refer to ldp container with trailing slash

Dmitir: +1 for adding it to spec

Tim: The folder always has a trailing slash. If the user types in something else then the server should redirect

<dmitriz> (adding the WAC-Allow header to the spec, specifically)

When the link is followed by the browser the server should redirect from one with the slash to one without

Tim: When you look at an acl file you can't tell if something is a directory or not so you can't make an acl file validator

Mitzi: I want to add defining who controls what data

Who controls derivitive data, or data generated by work employees.

Who controls data of baby or child, or data of the dead

<timbl> The URI of a folder always ends with a slash. The URI without the slash is not the URI of the folder, and should not be matched in an ACL file.

Justin: Solid as a spec allows you to manage control of who has permission

But the social context is really up to the application of the tech and that's going to be context based

I don't think it's appropriate to go beyond giving facilities to control

Like the web, you can apply it in many different ways

The Spec doesn't take an opinion

<scribe> NEW SUBJECT ===================================

<Mitzi> https://github.com/solid/solid-panes/issues/91

^^^^^^^ Chat invitations

Question of whether invitations should be sent to the global inbox or if there should be more specific ones

Some apps have a button to clear inbox

If more apps start doing that then there are going to be too many ways to clear your inbox

Better to have inbox for specific topics

<Zakim> timbl, you wanted to talk about inbox

Tim: The structure of the notifications flow is going to be really important to get right

We need to plan that. Somewhere there might be a clear my main inbox but there will be a mixture of different inboxes

And having sorts of things in inboxes

Like "Clear all alarms out of the inbox"

At the moment it's simplistic but we should sit down and take inspiration from things like RSS feeds

In general I'm in favour of having granular inboxes

Associated with groups I've joined

Justin: I think getting these event patterns right is crucial

You can look at it as a lot of different inboxes

You could subscribe to a bunch of different topics

Integrity of messeages is really important

You must trust senders of inbox messages

Do we need some kind of message signing for certain kind of messages?

We need to think about it and get it right

<dmitriz> https://w3c-dvcg.github.io/ld-signatures/

Dmitri: Agree with Justin about message integrity

ld-signatures could be an implementation of that

<Zakim> dmitriz, you wanted to mention Linked Data Signatures for message signing & integrity

Tim: MQ-series was an architecture that could be used as a message based pattern

Justin: You can use paterns from Kafka and RabbitMQ

<Zakim> michielbdejong, you wanted to talk about message signing vs linking

Michiel: Another simple way to chat a message was sent by somebody: I could include a link to something on my pod to validate that I sent it

Justin: The only issue with that is that is that it will have performance problems if you have to do a lookup to every server for each message

With signing you can process tons of messages

Tim: Another pattern is just sending a link that something on another pod has changed

<timbl> maybe a workshop about all the use cases for messages would be a good idea

Pavlik: We should discuss this on Github

<scribe> ACTION: ITEM to Michiel has opened an issue for this

<trackbot> Sorry, but no Tracker is associated with this channel.

<Mitzi> https://github.com/solid/solid-panes/issues/91

^^ Issue to continue discussion

<scribe> NEW SUBJECT ===================================

<Mitzi> https://github.com/solid/information/pull/146/files

^^ Dan has put together usage guidelines for solid logos

This is for people who build an app and want to identify with the solid movement

Jackson: I don't think the official solid styles should have roboto

Tim: main thing is to stick with purple but you can have multiple colors

Mitizi: you should mention any remarks in the pull request

<Mitzi> https://github.com/solid/information/pull/152

<scribe> NEW SUBJECT =========================================

https://github.com/solid/information/pull/152

^^^ Pull request to code of conduct to address why someone would get banned

2 cases to ban peopel:

Personal threats

Discriminatory Threats

Always reach out to people who got banned

<dmitriz> +1 to this pr.

+1

<acoburn> +1

<justinwb> +1

<elf-pavlik> +1

<michielbdejong> +1

<Matthias_Evering> +1

<michielbdejong> Mitzi++ for taking this difficult job on her shoulders

Should change wording to say "Will ban" to "May ban"

Would like the reestablish that it's not permanent

AGENDA END =================================

Think of ways to bring in people to help test various things we're developing

Start with a survey: Do testers know what node and npm are

But what would be better is for developers saying that they need a tester with particular skills

It might be a great learning experience for testers

And could help with developers

Jackson how many people are willing to test

Jeff: In my experience the only people who have responded are other testers

So we want to widen that, because there are people out there who are capable of working with web forms

So far I haven't encountered such people

Michiel: I want to do more app testing. Next Monday 3 people will be testing chat apps

I would also like to test the list of existing apps

Because there are a lot of apps that I haven't seen yet

I really like Jeff's suggestion of involving non-developers for testing

Right now the stance is that it's so easy to find bugs ourselves

On monday we should go through all the apps that you're aware of

Justin: I think we should also try to look at how to get some better focused app testing

I think there are a lot of people who would enjoy doing app testing

With others

Like a social experience

There's no real medium to focus that in a certain way

Mitzi: any thoughts of what we'd be testing for?

Dmitri: We could start with app developers saying what they're looking for feedback on

<justinwb> q0-

Matthias: I'm already a tester, but I'm not sure if I have the basics right

Maybe we should record the reactions

Update: Face to face in Paris is taking shape

11th of december

12th of december is the actual conference

The room has a capacity of 1000 people

The dates aren't in stone yet

Is there something that anyone would like to see at the conference?

Any final comments?

Are there any updates on the decision making process?

Mitzi: There are thoughts, but I haven't been able to translate that into official documents

Elf: I see this pull request as more general content

I would be interested to move somewhere with it

Is there general pull request content, or how do we continue with the spec

Mitzi: Probably we need to think about how to give things legitimacy

Sometimes everyone agrees or there's just a slight difference in opinion and that blocks it because we don't know what opinion prevails

One way: we have these issues and just chat about it on a pull request

This is more of a fallback process in the rare case that there is a difference in opinion

We don't want to get into an eternal cycle of minute votes

SEE YOU ALL NEXT WEEK!!!

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: michielbdejong justinwb elf-pavlik
Found Scribe: jackson
Inferring ScribeNick: jackson

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: item

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)