create long chat message on a new day fails due to the yyyy/mm/dd file structure

[ewingson]

it seems only the owner of the POD can post in long chat as first user of a new day. the problem occurred in https://solidarity.inrupt.net/public/ I got Web error: 403 (All Required Access Modes Not Granted) on PUT of <https://solidarity.inrupt.net/public/Solidarity/2020/02/25/chat.ttl> when trying to post in solidarity and the error was reproducable...

[jaxoncreed]

In this instance, all chat participants have read and append access to the chat container. Only one person has write access. So, on new days, no one can chat until the owner sends a message.

[michielbdejong]

Ah, that definitely sounds like a bug! We should try to reproduce it and try to think of a solution.

[timbl]

Interesting. Isn’t it logical that putting a new file into a directory should be possible if you have Append access. You are monotonically adding to the data. You should of course. not be able to overwrite an existing file without write access. So that would make it a server bug.

[timbl]

(A way to fix it at the client side would be to Use a patch instead of a put but let’s check the spec and fix the server

[michielbdejong]

let’s check the spec

The spec is currently in flux, so we can't check it there, unfortunately.

FWIW I looked into this and similar questions recently and wrote it up in an unofficial blog post about how Solid works; there I stated that:

A POST request requires Append or Write access on the container in which the resource is being created. A PUT [or PATCH] does too, but additionally it requires Write access to the URL of the newly created resource itself.

A way to fix it at the client side would be to Use a patch instead

Since with PATCH the client can also choose the resource URL, from how I interpret the Solid spec, that requires write access to the resource just like PUT, and unlike POST where the server chooses the resource URL.

So I think we're stuck with the current situation in the sense that creating a new day in a long chat requires write access.

Let's think about how we can work around that. Maybe all chat participants need write access, or empty documents should be created a while into the future, or participants keep using yesterday's chat until the chat owner logs in again to open the new file for the new day...

[jaxoncreed]

https://github.com/solid/web-access-control-spec/blob/master/README.md#aclappend <- This part of the spec uses appending notifications to an inbox as an example. Given notifications are resources, it would make sense to say that given an individual has append rights on a container, they can create a resource.

[michielbdejong]

@jaxoncreed that's POST, not PUT. The big difference is with POST you cannot choose the resulting location.

[jaxoncreed]

Ah makes sense. So would the solution then be to change the chat pane to not use POST and simply link the created file in the chat's index?

[michielbdejong]

It's not using POST, it's using PUT. That's why it's failing. But we could switch it from PUT to POST and give up on deterministic filenames, just use hyperlinks instead, smart!

[scenaristeur]

Hi @ewingson , it's really strange that you can't create a 'new folder day' on Solidarity. As you can see , Solidarity is the owner, but that user doesn't create each day. 26/02 has been instancied by @Julian-Cole, 27/02 by michaud... 29/02 by Stefan and they've got no particular rigths

We use Shighl, https://github.com/scenaristeur/shighl that use ldflex-query under the hood

[ewingson]

hi @scenaristeur just again got a Web error: 403 (All Required Access Modes Not Granted) on PUT of <https://solidarity.inrupt.net/public/Solidarity/2020/03/02/chat.ttl>

when it is NOT the first message of the day, everything works fine. @jaxoncreed got the same error. the info in your screenshot shows, there are other users than owner opening a new day.

this indeed seems contradictory for me. will you just for test reasons fire up a message for today and let me respond to demonstrate functionality ?

[scenaristeur]

First, could you try to post the first message directly with 'official long chat ' https://solidarity.inrupt.net/public/Solidarity/ to be sure it's a Long Chat /server matter, or Solidarity/Shighl/ldflex-query issue.

[ewingson]

the test message doesn' t go through with 403

[ewingson]

neither in ChatTest, Shighl nor Solidarity folder where in every three long chats it would be the first message for 2020-03-02

[ewingson]

further experiments could contain a vice-versa-test. do you want to try to open a new day with a test message in https://ewingson.solidweb.org/public/david/ ?

[scenaristeur]

new day 02 March opened here https://solidarity.inrupt.net/public/Solidarity/ but it seems that https://scenaristeur.github.io/solidarity/ has a bug (@Julian-Cole ) and show the 03 March, whereas https://scenaristeur.github.io/solidarity/archive/ show the good day.

I can't create a new day on https://ewingson.solidweb.org/public/david/ did you grant everyone to Poster

[ewingson]

second message for today went okay in solidarity..... now have granted posters 'everyone'

[scenaristeur]

i cannot post on your chat

[ewingson]

okay, and... when I open it up (which I just did) ?

[scenaristeur]

When the road is open ...

[scenaristeur]

it seems that there is something wrong with the solidos chat config compared to the "Solid W3C CG"

[michielbdejong]

This should be a lot easier if you use the new "create chat" functionality; it not only mints the chat thing, it also sends an invite to one other person you want to add to the chat, it adds it to your private type index, and it sets the ACL so that your yourself have read/write/control, and the other person has read/append on both the folder structure and the RDF docs that make up the chat.

[bourgeoa]

We could as a default on creation set ACL with :

• on folder structure : Control on the owner, ReadWrite to authenticatedAgent and Read to everyone.
• on index.ttl and chat.ttl : Control on the owner, ReadAppend to authenticatedAgent and Read to everyone

[Julian-Cole]

I think this bug relates to the Solidarity/Shighl code rather than solid; I recall there is an issue in Solidarity where users can be watching the current chat file for changes, and straight after middnight a user can post a new message into a new folder, but the other users are still watching the last chat file for changes. In Shighl ideally at middnight it would check for a new folder, or possibly something else.

I think for chat, Solid would need to augment with scaling chat helpers to get the last 50 chats etc but in a limited bandwith service way, so users can build scalable solutions to play with; you could probably apply this across the other common web service patterns Solid needed to solve, just a thought.

[ewingson]

a thought: I think the problem originates in the (relatively understandable) detail that all the others are append assigned, while only the owner has the write access to post the first message after midnight. that the 403 was reproducable hints to that. I'm not sure though what happens, if we grant read and write to authenticated agents. just an analysis, no suggested solution here.

[bourgeoa]

https://github.com/solid/solid-ui/issues/441

[bourgeoa]

closed with https://github.com/solid/solid-ui/pull/442