linkeddata
Normal save doesn't recognize file on remote server.
I've opened a file on my pod using a standalone deployment of dokieli.
When I attempt to save with the simple save button, the page attempts a PUT to itself. Given that I have it running as a static site in Nginx, this fails.
However, if I use the Save As function and specify the file in my pod, the save works correctly. It executes a PUT to the server hosting the pod. It also attempts to open the file on the pod directly, which seems a bit odd to me.
Now... It could be that my setup is very anomalous. I'm trying to self-host everything, which is an adventure to say the least. I have just a dummy HTML page with the dokieli scripts and css linked. I just use that page as a portal to open the desired file in my pod. When dokieli attempts the simple save, it's trying to PUT to the URI that the dummy HTML page is at.
Given that autosave does seem to save to the opened file location, I think the simple Save button is bugged.
(I'm also having issues with autosave thinking the remote is always newer than local, but I think that's an issue on my end. I'll troubleshoot that separately.)
@TheBeege Thanks a lot for reporting this! You're certainly on the bleeding edge since we didn't even yet publicly announce the new feature! :)
I'd like to debug. Could you share a bit more detail on file/resource you're trying to open. What format is it? If it is not sensitive, would you mind sharing it so I can test it locally?
I must admit, we didn't test how autosave reacts to "Open" after different kinds of local files or remote resources.
Just to be clear, dokieli is not intended to open any kind of format. For some (like HTML or concrete RDF syntaxes), there are some possibilities, including a view. But, right now, you can't open a random media file or something. While it is possible to browse the storage, views are naturally limited. Generally, authoring is about editable text content (at the moment).
If you'd like to join Matrix chat, we can also async debug there:
https://matrix.to/#/#dokieli:matrix.org
But here is also good for tracking issues.
Are you using the latest from this repo? Or is your HTML document referencing the JS/CSS on the dokie.li website?
When I attempt to save with the simple save button, the page attempts a PUT to itself. Given that I have it running as a static site in Nginx, this fails.
My assumption is the static site in Nginx doesn't allow PUT requests. Does it return a 405 error or do you get a 200 or 201 but the resource is not actually update. Something like this happens with npx serve - it is not configured for write operations. That said, I would've expected the "Save" feature to be disabled for you if you're not signed-in or have write access to where it is trying to save.
However, if I use the Save As function and specify the file in my pod, the save works correctly. It executes a PUT to the server hosting the pod. It also attempts to open the file on the pod directly, which seems a bit odd to me.
That's interesting. So you must be authenticated and have write access. It opens the file there assuming that's where you want to continue authoring. This is a somewhat similar behaviour to desktop authoring tools where "Save as" creates the new file and updates the view where you continue to edit on the new file. What do you think would've been a less surprising behaviour?
I just use that page as a portal to open the desired file in my pod. When dokieli attempts the simple save, it's trying to PUT to the URI that the dummy HTML page is at.
This is the intended behaviour. The target resource where Save should be performed is the URL that you see in the addressbar (without the fragment, if any).
Given that autosave does seem to save to the opened file location, I think the simple Save button is bugged.
I'd like to understand this better. Autosave should be working at the new location. I'm not sure why Save wouldn't work there though. Could you share any details from the Console or Network tab?
(I'm also having issues with autosave thinking the remote is always newer than local, but I think that's an issue on my end. I'll troubleshoot that separately.)
Please keep me posted on this. Remote may not necessarily be newer. Editing is supposed to happen locally (in the browser by the user), and when changes make it to the server (by any user) and the resource gets updated, then one's local copy (in the browser) would need to be synchronised. If there are differences between your local copy and the remote copy, then the UI should show a diff view and ask you what you want to do with it. If only remote changes, your local copy should update automatically (without bothering you).
Thanks for the quick reply. Sorry for the delay, as I was about to go to bed (and am again. Long work day).
I'd like to debug. Could you share a bit more detail on file/resource you're trying to open. What format is it? If it is not sensitive, would you mind sharing it so I can test it locally?
The file is an HTML file, linking the dokieli JS and CSS from a local copy. Contents are this:
<html>
<head>
<link href="/basic.css" media="all" rel="stylesheet" title="Basic" />
<link href="/dokieli.css" media="all" rel="stylesheet" />
<script src="/dokieli.js"></script>
</head>
<body>
This is a test.
</body>
</html>
I must admit, we didn't test how autosave reacts to "Open" after different kinds of local files or remote resources.
Autosave appears to work well despite the issue determining latest. Will address that more, shortly.
Just to be clear, dokieli is not intended to open any kind of format. For some (like HTML or concrete RDF syntaxes), there are some possibilities, including a view. But, right now, you can't open a random media file or something. While it is possible to browse the storage, views are naturally limited. Generally, authoring is about editable text content (at the moment).
Yep, and that's exactly my use case. We're good :)
Are you using the latest from this repo? Or is your HTML document referencing the JS/CSS on the dokie.li website?
I cloned the repo then copied them to my path being served. Eventually, I'll set up a cron job to compare checksums and update.
My assumption is the static site in Nginx doesn't allow PUT requests. Does it return a 405 error or do you get a 200 or 201 but the resource is not actually update. Something like this happens with npx serve - it is not configured for write operations. That said, I would've expected the "Save" feature to be disabled for you if you're not signed-in or have write access to where it is trying to save.
Correct. My Nginx server gives a 405, but that is expected. My issue is more when I open a file from my pod in CSS. I'm logged in, I've opened the file from the pod, and I attempt to save it. Despite having opened a remote file, the "Save" button still tries to update the originally visited page, not the opened file.
This makes sense if the original intent is to allow editing of directly accessed files, which may be the original intent. When I saw the Open and Save As features, I thought the intent was to generally operate as a general text editor, which is what I was looking for in the first place.
All that said, I'm not sure how the saving direct file makes sense, but I'm also quite new to Solid. To view a file behind ACLs, one must login. To login, one needs a viewer. If one is viewing a file through a viewer, it's not guaranteed that dokeili will be rendered unless the viewer simply renders HTML contents of the file. Given this, I don't understand the use case for direct file editing (i.e. without an Open feature) with dokeili unless a file is totally public or doesn't permit writing.
That's interesting. So you must be authenticated and have write access. It opens the file there assuming that's where you want to continue authoring. This is a somewhat similar behaviour to desktop authoring tools where "Save as" creates the new file and updates the view where you continue to edit on the new file. What do you think would've been a less surprising behaviour?
Yes, exactly on all counts. The interesting part is that Save As works as you described. I just can't use normal Save after that. I can consistently update the file if I use Save As on the same file, hosted by my pod.
This is the intended behaviour. The target resource where Save should be performed is the URL that you see in the addressbar (without the fragment, if any).
Ahh.... Ignore my previous comment regarding the use case not making sense. If the ACL permits viewing by all, then the file can be accessed in the pod directly, the user can login, and the user can save the file. I will try that shortly. I'm still figuring out ACLs. I know the concept, but the Solid format for ACLs is... well, it's trash, as I can tell. Can a brother get some JSON? Or at least some delimiters?
I'd like to understand this better. Autosave should be working at the new location. I'm not sure why Save wouldn't work there though. Could you share any details from the Console or Network tab?
Agreed. Save simply does a PUT to the file directly accessed by the browser via the address bar. Autosave acts like Save As, operating against the opened file at the remote location. The issue seems to be solely with Save. Basically, Save doesn't respect that a file is opened that's not the file originally opened by the browser.
Please keep me posted on this. Remote may not necessarily be newer. Editing is supposed to happen locally (in the browser by the user), and when changes make it to the server (by any user) and the resource gets updated, then one's local copy (in the browser) would need to be synchronised. If there are differences between your local copy and the remote copy, then the UI should show a diff view and ask you what you want to do with it. If only remote changes, your local copy should update automatically (without bothering you).
Agreed. I gotta go to bed shortly, so I'll play with this tomorrow. Maybe we should treat this as a separate issue, since I imagine the solution to be different.
@csarven
Already have an update. Easy test.
I fixed up the ACL to allow the pod-hosted version of my file to be viewable by all. I visited it in my browser, logged in, and was able to edit and use manual save normally. So for the visited file, Save works well. It just needs to be fixed up to respect a file that's opened remotely rather than the visited file.
I also have another update on the Autosave front. Basically, it doesn't update the file when there's a diff. My file looks like this:
Identifier: https://solid.beege.works/main/Home/f8686604-0313-4600-8530-6c1616499e40
Created: 2025-07-06
Modified: 2025-07-06
Latest Version: https://writing.solid.beege.works/cbfc8b4a-745e-4729-8bc3-0f0e761f4302
Derived From: https://solid.beege.works/main/Home/f8686604-0313-4600-8530-6c1616499e40
Derived On: 2025-07-06
This is a test.
Let's see if this saves properly.
Can we overwrite?
Test with manual saving.
Manual save as works. Manual simple save gives a 405 error, but it seems to be trying to save to the writing server, which is just a frontend-only Nginx server. Autosave seems to have ETag matching errors.
Trying manual save for file viewable by anyone but only editable by owner.
Check that header information. That is added by either dokeili or CSS; however, it's part of the document contents that the user edits directly. Have you found the issue yet? If so, you're smarter than me.
When I try to save my local copy, I didn't update the Modified value. When dokeili saves the file, it automatically updates that value. So my local and the destination truly are out of sync. My local didn't update the Modified value. I don't think this header data should be considered content. Not sure how to better do it, but... Well, I'm not smart enough to be building dokeili, but you are! :D
Edit: Right, didn't address the actual problem...
If I override my changes to accept the changed Modified value, I can save, and everything is cool. However, if I force refresh the page, it appears to match, but I still get the Autosave diff pop-up coming up, stating that my original version without the updated Modified value is out of sync. That's the bug.
Thanks so much for following up.
Despite having opened a remote file, the "Save" button still tries to update the originally visited page, not the opened file.
Long story short because there has been some changes over the years on "Open":
Made some updates yesterday to make sure that after New/Open, Save will now actually trigger Save As. We need to transition Open to more like Import where it dokielizes the document (adds JS/CSS to it), if it doesn't already include dokieli, and then saves it at that location, then change the address to it so the user can continue from there.
(because as you encountered, while at x, opening y doesn't make sense as far as saving it as x goes. And, we can't simply change the addressbar location (if y is under some other authority) because of same-origin rules.)
Opening a GPX file however at the moment embeds a map/data at the bottom of the current document. We could move that feature from Open to Embed or something.
To view a file behind ACLs, one must login. To login, one needs a viewer. If one is viewing a file through a viewer, it's not guaranteed that dokeili will be rendered unless the viewer simply renders HTML contents of the file. Given this, I don't understand the use case for direct file editing (i.e. without an Open feature) with dokeili unless a file is totally public or doesn't permit writing.
At the moment, dokieli doesn't act as a storage navigator of some sort where the user has control access on everything. But this is true for any part of your storage. In order for you to view your storage, you need to authenticate somewhere, some app allows you to do that - SolidOS is one that comes with some Solid servers out of the box, and that lets you sign-in and then you can see your storage, and assign permissions that way. So, don't look at dokieli that way. Right that at least one HTML in which dokieli can be viewed - whether you are signed-in and have read access to it or a public-read HTML of dokieli somewhere. Either way, once you can view a dokieli HTML, you can also sign-in from dokieli. I understand your confusion, so you're not alone on this. Everyone gets tripped up by this. All this stuff is not crystal clear both in terms of UI and documentation. There is also separation of concerns. Dokieli is not trying to do "Drive" like stuff - or at least not particularly in plans right now. See Roadmap if curious.
The interesting part is that Save As works as you described. I just can't use normal Save after that.
It may be base URL related. Will test. But:
Is that because the HTML file that you created which you use to open a file is served from nginx? When you click Save, do you see a PUT request and can you share more details on that? If the response is a 200, then the server is ack'ing the request but it is not actually doing write updates internally. That's out of scope for dokieli. If you are getting a 401 or 403 or something else, we can look into that closer as well.
I know the concept, but the Solid format for ACLs is... well, it's trash, as I can tell. Can a brother get some JSON? Or at least some delimiters?
You're probably seeing Turtle but depending on the server, you may be able to use JSON-LD. I don't want to get into this right now though in this issue because it is rather out of scope for dokieli.
Basically, Save doesn't respect that a file is opened that's not the file originally opened by the browser.
Right. That needs to change because of how Open works. If we solve Open, Save is not the issue.
I fixed up the ACL
Generally, you can give yourself acl:mode acl:Read, acl:Write to do read-write operations, and acl:Control to change access permissions (see the Share feature from the menu). You can also have a rule like this for your internal testing or protected environment where you don't need to be authenticated - it is like public read-write-control.
:readwritecontrol
a acl:Authorization;
acl:accessTo <test.html>;
acl:agentClass foaf:Agent;
acl:mode acl:Read, acl:Write, acl:Control .
I visited it in my browser, logged in, and was able to edit and use manual save normally. So for the visited file, Save works well. It just needs to be fixed up to respect a file that's opened remotely rather than the visited file.
Great! Right!
Check that header information. That is added by either dokeili or CSS; however, it's part of the document contents that the user edits directly. Have you found the issue yet?
If you are referring to document-level information like identifier, created, modified, latest version, derived from, derived on, then yes, that's dokieli. The Derived info can be left unchecked if you don't want it when you do a save as.
My local didn't update the Modified value. I don't think this header data should be considered content.
IIRC, if there is no modified, and dokieli sees that server makes Last-Modified header available, then it will make use of it. If you don't like this, you could edit and remove it.. but I guess we should revisit this UI. We need to balance between stuff that should be handled automatically for the user and stuff that should not be put that the user didn't want. Hard to make a call. Dokieli is intended to be human- and machine-readable, and so sometimes the human-readable part may seem verbose. Will come back to this.
If I override my changes to accept the changed Modified value, I can save, and everything is cool. However, if I force refresh the page, it appears to match, but I still get the Autosave diff pop-up coming up, stating that my original version without the updated Modified value is out of sync. That's the bug.
Interesting. Will investigate.