The need for this occurs about every two weeks as university guest passwords expire. I copy and paste to save the generated password until a successful login, then paste to update the BitWarden entry manually. I, too, don’t see a philosophical issue other than asking [if a conflict exists] which update to accept [or ignore all?]
I’m just curious about why your use-case occurs in an off-line environment?
Go to university web site..
Find out account has expired.
Ask for new account and get new password [and, often, user ID but I use
ME+uni1 2 3 …@gmail.com
Try to login to web site with new account info by editing BitWarden entry.
NOGO
Perhaps ask your university if they would allow access to vault.bitwarden.com and vault.bitwarden.eu on their guest network prior to authentication.
At this point, you clearly do have internet access (i.e., you are not off-line).
So this part you are doing in person, at some kind of help desk? Is that why you are off-line while resetting your password?
Not if that university web site was some kind of captive portal (like those found in many wi-fi’s that don’t let you access the Internet until you authenticate).
1 Like
@grb - a lot of discussion trying to understand the needs for this, but the above 160+ comments clearly outline some sensible offline/occasionally connected use cases.
Given how long this has been roadmap:planned and towards the top of the list (most votes) it appears there is some strong objections or difficulty in getting this up.
Can any insiders shed light on this? Is it just super complex? Is there a philosophical objection?
Any insights to share @Quexten @djsmith85?
Should we hold out hope?
1 Like
No philosophical objection I’m aware of, just not prioritized yet, compared to other much needed work. Though, it is internally tracked that this is a much demanded feature. I’m aware that there was already a prototype for offline editing for mobile made.
Some hidden complexity:
Assume you have two offline phones, and edit an item I on device A, and device B. Then both devices come online and sync. Which version of I should be the one saved on the server? The one that syncs first? The one that syncs last? The one where the local device time at the time of editing was never? Should these be merged?
Of course, this is an edge case, and a default behavior would be much nicer than where we are currently at.
1 Like
I was only trying to get some clarity about the specific situation mentioned by @Joe_McDaniel.
Wouldn’t this already be handled by the existing code?
As an initial implementation, I think it would be OK to only accept off-line edits that have no conflicts.
Those who want these features may also be interested in voting for the relevant feature request about full history revision. Without a full history revision, it is impossible to edit offline without risk of losing substantial information.
From Edit conflict - Wikipedia,
The simplest way to resolve an edit conflict is to ignore intervening edits and overwrite the current file. This may lead to a substantial loss of information, and alternative methods are often employed to resolve or prevent conflicts:
- Manual resolution, where the editor determines which version to retain and may manually incorporate edits into the current version of the file.
- Store backups or file comparisons of each edit, so there are the previous versions of the file can still be accessed once the original is overwritten.
- File locking, which limits the file to one editor at a time to prevent edit conflicts. Computer writer Gary B. Shelly notes that many wiki systems “will block the contributor who is attempting to edit the page from being able to do so until the contributor currently editing the page saves changes or remains idle on the page for an extended period of time.”
- Merge, by determining if the edits are in unrelated parts of the file and combining without user intervention.
1 Like
I don’t think the other thread is directly relevant to this one, and what you wrote above is an overstatement. Depending on how Bitwarden decides to handle ambiguous scenarios such as the example described above, they would at best only need to store date/timestamps of the most recent change on each device, or at worst store only changes made since the most recent synchronization event for each logged-in device. In contrast, the thread that you linked also requests storage of changes made prior to the most recent synchronization event — i.e., the history of those changes should be retained after synchronization, which is not necessary for the purposes of implementing off-line editing. Another major aspect of the feature request that you linked is that the stored history should be visible to the end user, which, again, is unnecessary for the purposes of implementing off-line editing.
I don’t think what I wrote above is overstatement. I think you’re confused about what an edit conflict is and what it’s like.
If you and anyone think that always leads to an edit conflict, think again. If two people are editing and/or sending edits at the same time, it’s not usually a conflict unless one of the edits causes the other one to be deleted.
Yeah, that’s totally doable.
But…
While you’re right that you can only keep the changes made since the conflicting edit to solve the conflict. But if you just apply a merge algorithm and accept it without the user doing anything, it could lead to an unpredictable outcome because the algorithm only handles textual conflicts (conflict that can result in lose of information, not syntactic or semantic ones.
Things get complicated when we consider that Bitwarden data is end-to-end encrypted. This makes conflict resolution approaches such as operational transformation (OT), which Google Docs uses, impossible without sending unencrypted data to the server.
I was referring to your claim that offline editing would be “impossible” (without risk of data loss) unless a “full” revision history is available.
Your response does not dispute this:
What am I missing here? In my last reply, I gave you my thoughts on your proposed solution, which I think is a bad idea. So, your last argument doesn’t prove my claim wrong. Just a heads-up: I’m not saying my claim is 100% true. If you or anyone else has better ideas that aren’t too far out there, I’m all ears.
Perhaps you misread my comment, as I was not proposing any solution. I was merely pointing out that to implement offline editing, at worst, Bitwarden would need to store a history of local changes made since the most recent sync (and that none of this history would need to be exposed to the user in order to implement offline editing). Therefore, the other feature request that you are promoting here (“History for all fields like Password History”) is not directly relevant to the current feature request about Offline Editing.
If further off-topic discussion is posted here, the off-topic comments will be moved to the other thread.
Thanks. Noted
I just found out that Standard Notes duplicates items when there is a conflict. Maybe that’s what you want; it eliminates the need for a full or visible history. So my previous claim is not entirely true.
Yes, I agree know.
If you think it’s off-topic, feel free to split the comment.