Yes, That is exactly what I want.
Treating someone who is using the Electron app directly as an owner, and anyone accessing via a browser as an anonymous guest.
Electon app is out-of-the-box without any config and settings, that is super convenient.But if I want to publish my document officially, I would run it with https, sandboxing and auth on docker.
Great @7c9zfztk, sounds like you know what you are doing. I put out a new version (0.1.5) at Releases · paulfitz/grist-electron · GitHub. It has a new setting, GRIST_ELECTRON_AUTH. If you set it to mixed, it should do something close to what you want. Anonymous access will be possible, but although the sign-in button is still there, clicking on it outside of the Electron app should result in a denial. And you don’t need to touch GRIST_FORCE_LOGIN.
@Sylvain_Page if you use this version, I think for what you do you’ll need to set GRIST_ELECTRON_AUTH=none. I’ve tightened up the default access level.
I’ve started summarizing configuration options in the repository’s README.
Thank you @paul-grist , 0.1.5 works exactly as I expected.
Hi @paul-grist ,
Same for me 0.1.5 work as expected GRIST_ELECTRON_AUTH=none for me, thanks !
Hi @paul-grist ,
I have noticed that with grist-electon >0.13 docs are saved directly in users docs (no folder).
Previously it was saved under “grist-electron root directory”\docs*.grist
Is it possible to keep or specify this setting to avoid mess in usr\docs
Also when upgrading I’m importing previous docs files manually. When doing this it gives another internal id and I then need to update my anchor-link.
Is it possible to ask in Grist-Core if we want to keep the old id ?
Thanks for the feedback, I was wondering what the best to do here would be. If you were starting over, what do you think the best default is? Inside a “Grist” subdirectory of user Documents? In any case: you can set GRIST_DATA_DIR to the directory you want Grist to keep .grist files in.
Hmm, I guess that Grist’s internal “landing.db” that knows about these ids is now in a different location. You could set TYPEORM_DATABASE to point to the old location. Together with GRIST_DATA_DIR you might be able to pick up from where you left off.
Sorry for the changes … but I can’t promise they will be the last ones prior to an eventual version 1.
No pb that’s a minor issue for me.
I think I can also have a work around with formula catching id with something like SELF_HYPERLINK()+$Location_Cell (no pc to test right now).
Update: along with Windows and Linux, there are now working Electron packages for Mac (Intel and ARM - thanks @georgegevoian for testing!).
A set of patches that makes building for Electron easier has been added to grist-core so it should be less work now to keep the Electron build up to date with self-hosted Grist and our SaaS.
If anyone has a good-looking screenshot of their desktop with Grist on it, especially for Windows, I’m looking for samples for the project’s README 
Thanks for the project.
Is it possible to somehow use the Electron version as a worker for a remote Grist server. That is, when the Grist Electron app is launched, users work with data on the server and at the same time increase the overall performance of Grist by increasing the workers in the system?
Short message to say webhook works nicely with electron app.
Hi @BiBo , no, that’s an interesting idea, but not something anyone has built yet as far as I know.
Update: the latest version of Grist Electron has sandboxing enabled by default. It is a new form of sandboxing, since the existing mechanisms we had either didn’t work on Windows or were long deprecated. It has been working ok for me so far - if anyone sees problems please do let me know. I updated the README with information on how to disable it, just in case.
Hi @paul-grist ,
Do you plan to release a new rev of grist-electron based on last improvements ?
Many thanks for you work !
Will take a shot soon - if a week goes by without progress feel free to nag me
@Sylvain_Page there’s an updated package at Release 0.2.2 · gristlabs/grist-electron · GitHub, would be interested in if it works well for you.
Hello @paul-grist ,
Many thanks, I am unfortunately quite over busy and take risk to break anything at this moment.
I expect to give you a feedback by next week. Thanks for your continuous efforts on this topic.
I confirm tools developped with Grist satisfies our Direction versus standard heavy tools not appropriates to our needs.
Thanks Grist Team
Got few minutes to do the job → latest release installed successfully
All previous functions are Ok + new feature ok.
Webhook interface not tested
Maybe it’s time to update the build? 
Hello.
I encountered a strange problem, there is a need to import a large Excel file into Grist 20,000 rows about 40 columns.
Since the self-hosted version of grist does this very slowly for me, I decided to import it into Grist Electron, process the data and transfer the document to the self-hosted version of grist.
While running Grist Electron I get the following error:
[Sandbox] [Sandbox] PipeFromSandbox is closed: 1: 00007FF69AF42376 node::Buffer::New+47862
2: 00007FF69AF424ED node::OnFatalError+317
3: 00007FF69D9CB3B3 v8::internal::WebSnapshotDeserializer::UpdatePointersCallback+787
4: 00007FF69D9CB347 v8::internal::WebSnapshotDeserializer::UpdatePointersCallback+679
5: 00007FF69DA43C27 v8::CppHeap::CollectGarbageInYoungGenerationForTesting+65495
6: 00007FF699C25EC4 v8::CppHeap::CollectStatistics+86180
7: 00007FF69C756AB1 v8::CppHeap::GetHeapHandle+68401
8: 00007FF69C7489F0 v8::CppHeap::GetHeapHandle+10864
9: 00007FF699D533DA v8::internal::TickSample::GetStackSample+113674
10: 00007FF61FED7DBC
And until I restart the program, the errors continue when working with the document.
Does Grist Electron have any resource limits? Or do I need to disable Sandbox somehow?