#1

I need a way to provide highly complex Obsidian notes for easy, secure browsing by clients. Clients just want access to their notes from our sessions, not to edit or add to them. And they want the simplest possible interface.

Two possible solutions come to mind:

  • Add a vault setting which makes the entire vault view-only.
  • Create a separate Obsidian Viewer app.

The best solution would provide the minimum necessary functionality for easy browsing of the vault, removing everything more suited to creating and editing.

I’m guessing there would be many other applications for enabling users to share vaults with non-Obsidian users.

Bonus: it gets a version of Obsidian into the hands of new potential users.

(Thanks to @0x4A for helping clarify this request.)

7 Likes
Export a complete vault as single html
#2

My suggestion would be for you to identify the changes in Publish that would make it work for you.

Also strikes me that some of what you want could be done with CSS, effectively hiding elements that would make it less useful for your client. In which case you could design the vault, and then put it into a folder with Obsidian, encrypt the folder and give it to the client. It would open with the purpose-built CSS.

#3

I would like something similar for my own personal use; Ability to “lock” specific notes (like my Index note) so that I or someone else are unable to edit them. Some ideas: A password could be required when trying to edit the notes. Prompting when trying to edit the notes.

It just takes a few backspaces for the Index to get destroyed :slight_smile:

1 Like
#4

Is it important that your clients do not accidentally edit the vault you send them, or do you require that vault to be secure from edits, because there’s a sizable difference between those two ideas. A requirement of absolute offline security could push Obsidian right out of the scope of what you’re trying to accomplish, depending on how far down that rabbit hole the developers are willing to go.

The Viewer idea is neat, but one would have to conjure up an incentive to build and maintain another piece of software. Obsidian is supposed to be free, with a business model built around optional online services.

Maybe the most effective strategy right now is to wait. Once Publish is allowed to mature, the addition of a few often-talked about features could change your perspective of the problem. Custom domain names, custom style sheets, password protected online vaults - with those you could conceivably host read-only client vaults at your own business domain. It breaks the requirement of offline-only, but it’s elegant, and far more likely to already be on the roadmap somewhere. Is the offline-only thing a hard rule?

2 Likes
#5

Thanks for your questions, @0x4A.

  • Good distinction on security. For my purposes, it’s all about accidental editing, not being secure from edits. Even more important though is the desire to simplify and remove the likelihood they’ll go down a rabbit hole by mistake. The more I think about it, though, the more I like maintaining the option for them to switch modes and re-activate editing capacity. For example, once our work is done they may want to continue using Obsidian to do the work independently.
  • Along those lines, creating an independent Viewer or adding a View Mode setting would get Obsidian into the hands of more users. Browsing others’ vaults would be a great way for people to fall in love with the whole PKM paradigm and with Obsidian as a way to implement it. Currently Obsidian and similar apps are in early-adopter phase and this kind of functionality would help mainstreamers join the movement.
  • I doubt Publish will be a solution, for me at least. Clients will want to store their notes to look at years later without having to pay for hosting. So in my case, yes, offline-only is a hard rule. Plus, I would need to maintain a separate vault for each client. Paying for hosting for each that would need to be maintained indefinitely after our work concludes doesn’t make sense.
  • That said, waiting will surely yield other benefits, foreseen and not. For example, WYSIWYG editing will make the whole thing much friendlier to people intimidated by the coding feel of markdown.
#6

Thanks for your suggestions, @Dor.

  • About Publish, I’m pretty sure that won’t be the best path. It’s important that sharing notes happens offline. Creating a simulated online experience, for example using the Publish functionality to export a locally-viewable HTML5 package, likely undermines the Obsidian Publish business model. (Thanks to @0x4A for pointing that out.)
  • Your idea about using CSS to hide elements seems brilliant. Would that work in the desktop app? How do I figure out the underlying tags to be able to hide them – say, for example, for the pencil icon at the top of each note window?
  • Finally, are you saying I could just grab Obsidian.exe and put in a folder containing itself and the vault folder, and that would function without their having to install Obsidian on their system?
#7

If I was doing this, I would have a specific folder in the vault for each client. I store my vaults in iCloud on macOS, but the following would be applicable with Windows and/or with Dropbox, OneDrive, etc.

In iCloud, I would share just that folder with the client, in read-only mode. They can of course copy a document from that folder and put it elsewhere and do what they want. This gives them a view into only the notes they need to see, and protects me from their editing what the client should not edit.

2020-10-10_11-51-14
2020-10-10_11-51-14820×544 78.7 KB

#8

No, they’d have to install it. And it assumes they have a compatible system - but will any solution. It’s just simpler and stops them downloading a video game.

#9

Yes, it ought work.
I’m probably not the best person to advise on how many CSS tweaks would be needed. I try to avoid delving in the CSS - I’m well aware it could be a time sink if I did. You’d obviously set the vault to open in preview.

EdElgar’s idea could work in conjunction with this if they’re happy working with it. But it’s more complex because they’d either have to download files or use a cloud vault themselves.

#10

My solution to all such questions is to set up a dummy vault and play.

#11

@anon27868835 I can see that working for some workflows. For me, though, the client is “looking over my shoulder” at the notes as they are created, by me sharing screen during a session. Plus, my folder structures are extensive and need the full space of the left sidebar for optimal use. Best for each client to have their own vault.

Otherwise, yes, I’m on Dropbox, and sharing the client’s folder is a good way to make it accessible to them.

#12

Remember that all the client vaults can be nested. In which case, remember to add attachments while in the nest.

#13

Thanks @Dor!

On their installing Obsidian, yes, makes sense. Some are on Mac, others on Windows, probably OK to just point them to obsidian.md to download and install rather than packaging the file with it.

Looking into CSS, I started taking your advice to dive in and play. Just discovered there’s freakin’ developers tools interface!!! I had no idea. And yes, it seems straightforward to just hide some of the interface to simplify. Very cool!

Which suggests… a View Mode setting should be pretty easy to implement in the app.

#14

One question that comes up in talking about nested client folders is size. Just to give you an idea, one client’s current file would occupy 200 files, most with images, and a total of 250K words of text, current file size approaching a gig.

Given a passel of clients, how would Obsidian handle large amounts of data in a vault?

#15

Should be OK, but, if it ever slows, just start a new top vault. Like having a new filing cabinet. Except easier.

#16

Maybe I’ll ask an obvious question, but what prevents someone from opening the markdown file with some other editor and making changes? Or is the point to somehow also hide the markdown files so they’re not accessible outside the “viewer”? This to me sounds more like an export option to HTML as described here: Local Publish/Export Package: Convert contents of a vault into a single, browsable HTML5 (or other) file for secure sharing with non-tech-savvy clients

Edit: Just realized that both posts are from @joeshirley, which explains why they sounded similar! AFAIK the HTML export is on the pipeline (although not as a single file), while the viewer from my point of view might be harder to implement.

#17

AFAIK the HTML export is on the pipeline (although not as a single file), while the viewer from my point of view might be harder to implement.

As in the same thing as publish, but local?

This would be very handy to have, especially when I want to share some rendered notes with coworkers, and to have a publicly published version of a “Digital Garden”. Plugin behaviors, embedded links…etc all maintained

#18

Following @argentum comment, I am gonna close this and keep the export vault as single html open.

#19