Add "Folders" to Bookmarks to collect Bookmarks into Categories

[craigarno]

I find the Bookmarks feature really useful since I find myself in many different locations and on different computers. So I collect a large number of bookmarks.

To help me organize my Bookmarks, I'd like to request a new "Folder" feature in Bookmarks so I can group related Bookmarks together. I'm attaching a picture to help explain this concept. This concept is very similar to how Firefox and Chrome organize bookmarks.

I should probably mention I'm using OwnCloud 5.0.5 on OpenSUSE 12.2 x64 LAMP setup, and am brand new to OwnCloud.

Thank you, Craig

[rnewman]

I agree that the current bookmarks API could do better in providing details on what exactly changed, but as you said you can still perform a diff, even if that's expensive.

This is one reason why transactions are important: without isolation at some level of the stack (explicit transactions, implicitly isolated batch APIs, serialized synchronous notifications…) you can't reliably compute diffs, either incoming or outgoing.

However, if you sync less frequently in a fixed interval instead of on every change, collisions are much less likely to happen

Yes, if you can guarantee that no local changes will occur while you're applying incoming changes, or while uploading outgoing changes, then you can avoid both collisions and inconsistency due to lack of isolation — this is isolation via wall-clock serialization. However, it's not actually a guarantee — without true isolation and atomic changes there's always a chance of seeing a partial state in-flight — and at scale everything that can happen will happen.

you might not preserve every user intention if you move a folder from a to x when it's actually just been moved to b a few microseconds before, but at least the sync sites are consistent.

Consider what happens if you're trying to build a tree or perform an upload by repeatedly querying the local store. You might see a moved item twice or not at all, or miss a deletion, or whatever. Your results will be inconsistent.

This is really easy to get wrong in ways that aren't apparent when testing.

The only reliable way to do this kind of thing is by having storage itself do the bookkeeping.

Also, how likely is it for multiple extensions that move bookmarks around the place to be installed at the same time?

That would be wild speculation.

We've seen users who use both Xmarks and Firefox Sync, certainly. We've also seen potential issues interacting with add-ons such as Snooze Tabs, which generate synthetic bookmarks during browsing activity. There are add-ons that generate bookmarks as you browse.

But you can hit problems simply by having user activity overlap with a sync; add-ons just increase the rate of activity.

[marcelklehr]

Also, how likely is it for multiple extensions that move bookmarks around the place to be installed at the same time?

That would be wild speculation.

Yep, that's true :)

you can't reliably compute diffs, either incoming or outgoing

What about browser.bookmarks.get(Sub)Tree, though? Afaict it spits out the whole tree as an object immune to modifications by the user or other extensions. In one call. This should be sufficient to do a safe diff, imo. Unless the implementation of that method isn't atomic, of course.

If I'm manipulating the live tree based on a diff I took against incoming data and something gets changed (other than the bookmark's id, if that is changed all bets are off), I can still apply my patches. The problems I get are "merely": Overriding user changes of urls, titles or positions of items (perhaps even reviving deleted ones). No duplicates (unless two devices created the same bookmark concurrently). No deletions of newly inserted items. So, I get collisions, but I have consistency with the server state for those items that I already know about.

In essence, my argument is: If you reduce the probability of collisions occurring by reducing the sync frequency, you can reduce the probability of overriding user changes that occur during the sync process. And, as you said, at scale everything that can happen will happen, however, you will never get an inconsistent state that the program cannot recover from. The worst case is, that the user looses an edit they made during sync, which in my opinion is better than having no sync.

[maverick74]

The worst case is, that the user looses an edit they made during sync, which in my opinion is better than having no sync.

Not being much of a technical guy, but i agree that having some sync is better than none. Also, has a xmarks user, i can tell that when one forces a sync xmarks freezes the browser (only allowing you to move the sync window) to prevent changes during the sync process

[rnewman]

What about browser.bookmarks.get(Sub)Tree, though? Afaict it spits out the whole tree as an object immune to modifications by the user or other extensions. In one call. This should be sufficient to do a safe diff, imo. Unless the implementation of that method isn't atomic, of course.

If it is atomic, you still need to capture the entire combined subtree of all changes, so for a move that might mean fetching and diffing the entire bookmarks tree each time.

Non-atomic local application isn't just limited to potentially losing local user changes. Content-based smushing, for example, relies on the local data not having changed since you last looked at it. Inserting records, too — what happens when you download five new records, and the user deletes the destination folder before you've inserted them all? You can't just abort and try again — the local insert isn't atomic.

You also need to detect local changes during the sync (both inbound and outbound phases), and ignore your own, otherwise you'll miss changes and your clients will diverge. This is really tricky to do with just observer notifications.

Like I said: this is hard to get right for the simple case, really hard to guarantee eventual consistency in the presence of races, and even harder to get right and still have acceptable performance for non-trivial amounts of data. Between two clients and a server you have a distributed transaction each time the user makes a change — the change has to commit in three places — and so without really noticing we're deep into distributed systems theory!

when one forces a sync xmarks freezes the browser (only allowing you to move the sync window) to prevent changes during the sync process

That's not a bad option. Well, it's bad for responsiveness, and we probably couldn't ship that behavior, but it certainly avoids most local races.

[jkaberg]

I just want to chime in on the "sync on change" vs. "sync on cron" topic: My usecase involves adding bookmarks every now and then, which can be anything from 2 bookmarks a day up to 1 a month (often the latter). So for me "sync on change" is a lot more appealing as it doesn't cost that much (vs syncing every 20 min) in the long term and I get the change instantaneously.

Just my 2 cents 😄

[marcelklehr]

(Sorry for my absence in this discussion lately...)

what happens when you download five new records, and the user deletes the destination folder before you've inserted them all?

Since the user deleted the folder anyway, what's the point in trying to insert the bookmarks? Since we're dealing with one user only, I tend to assume, they are aware of the newly inserted bookmarks at the other site, when they delete the folder.

You also need to detect local changes during the sync (both inbound and outbound phases), and ignore your own, otherwise you'll miss changes and your clients will diverge. This is really tricky to do with just observer notifications.

If I have an immutable snapshot of the bookmark tree, I don't need observer notifications, which are, as you said, hard to attribute to an actor, and I don't really need to watch out for changes while I'm manipulating the live tree, as those will only cause the edge cases I've covered above and will get picked up in the next diff.

[marcelklehr]

@jkaberg Yes, onchange is always better than on interval. I can imagine finding a compromise between the two, where a change can trigger a sync, if it doesn't happen too often, but syncs also happen regularly, to poll the latest data from the server.

[marcelklehr]

It's kind of funny that we're debating webextensions in here and how to add folder support to nc/bookmarks over here: https://github.com/marcelklehr/floccus/issues/5 :'D

[jonas2515]

Is anybody working on this at the moment? If someone is, can we expect folders in the near future?

[1ucay]

Sorry for OT: In Windows 11 will be introduced new function. Microsoft from native filesystem removes folders, BUT there will be tags, which can be soo userfull for searching our data. Bookmarks are as files. We need some human organization in url mess :)

[maverick74]

By "as files" you mean a file for each bookmark?

[mikeziri]

jumping late to the discussion. after reading all the replies since 2013 I can't seem to understand why wouldn't, a bookmarks api like this, have folder tree structure on the db. I mean, tags are fine. I don't know who uses them and how but on a web browser like chrome, firefox and safari, everything is folder based. even a filesystem is directory (folder) based or everything would be a mess.

I think this should be implemented along side tags. a hack around would be to tag bookmarks like Amazon S3 does and some one suggested in another issue with tag: /path/for/bookmark

[v3nd3tta1337]

IMO Nextcloud Bookmarks is completely useless to users without having folders. A Exported bookmarks.html in NETSCAPE! compatible Bookmarks format has more function than this. If I want to search (for tags), i want to search (for tags), if i want to organize, i want to organize.

[beng7]

+1 desperately awaiting the support of folders, otherwise indeed it is almost useless (only a record of my bookmarks) I use Floccus for FF + NextCloud Bookmarks on my android (AOSP) phone

[TraceyC77]

+1 Overall I really like the bookmarks UI and the ability to access them with a browser addon. My own use requires folders and subfolders to organize information.

[edrush]

+1

[serioustk]

Same here. Struggled about this and cannot understand why folders aren't supported. I really need this to organize my bookmarks.

[joeplus]

+1

[maverick74]

Since Xmarks.com is saying goodbye in about one month (May 1st), there will be a lot of people searching for alternatives!

Would be a good time to move this feature forward and present it as a viable alternative!!!

[Lantizia]

I completely agree that folders are needed in the Bookmarks App.

At the moment the closest thing are the 'tags' that floccus creates in order to store the information that'd be needed to recreate folders natively in browser bookmarks.

This is fine but it does mean that since there is no proper folder support, you can't store an empty folder. Empty folders can be very useful for planning, for arranging your bookmarks bar properly, etc...

See... https://github.com/marcelklehr/floccus/issues/83

[prog-amateur]

Sorry but I insist on @Lantizia's request : folders are indispensable to organize bookmarks. I have imported an html file containing all my bookmarks (which have been organized by folders) and what I see is a list of all my bookmarks, unsorted, unorganized, with empty tags. I have maybe 500 bookmarks... so folders are necessary, I would say "vital" for all people who doesn't start bookmarks from scratch.

Please could you integrate this feature ? Thank you.

[Lantizia]

@prog-amateur Take a look at the floccus project, there is an open issue which is picking up traction where I've suggested they use something other than Nextcloud Bookmarks App (e.g. XBEL or JSON file stored on a WebDAV/Nextcloud/ownCloud server). This eliminates all the inflexibility that is currently an issue with this app.

To be honest I think I've fallen out of favour of using this app. If it wasn't for the fact it uses Nextcloud authentication... it may as well be a separate PHP development entirely, as it doesn't need WebDAV/files (what I see as the main point of Nextcloud) to work, it's entirely database driven and has a very strict ideology on how bookmarks should be done which just isn't reflected in the space we actually use bookmarks... browsers!

[IzzySoft]

Almost to the day, it's now 5 years since this request was raised. The initial post was "upvoted" 20 times, and many more users added their "+1" in comments. Strange this issue still neither has an assignee nor a milestone – which suggests the team feels it unimportant. This is quite frustrating. It makes me feel that, though many users feel this feature important, we can discuss it as much as we want but won't ever see it.

Thanks to @marcelklehr for participating and insights, though! But after 5 years "staying around": is there some hope we will eventually see this feature?

[HLFH]

@IzzySoft ownCloud & Nextcloud were mostly supporting Firefox Sync for a long time. But it has been deprecated in 2015. The new Firefox Accounts-based Sync solution has been quite a disappointment in terms of easiness to deploy in production. Maybe it has little changed now. Nextcloud Bookmarks is not a core feature, also bookmarking is an old concept that has been replaced by read-it-later solutions such as Wallabag, that are a step forward in the curation journey. Jan-Christoph Borchardt @jancborchardt from Nextcloud had the wonderful idea to start a collaboration between Nextcloud & Wallabag. Wallabag supports tags. I would advocate for going to this direction in the next two years, depending of the good will of the Nextcloud & Wallabag contributors. Considering the choice of Nextcloud by the German government, as a French supporter of ownCloud & Nextcloud since the beginning of the fight for data privacy, I can only applause and stay greatly positive for the future of Nextcloud.

[IzzySoft]

@HLFH

Nextcloud Bookmarks is not a core feature, also bookmarking is an old concept that has been replaced by read-it-later solutions such as Wallabag …

Sorry, but I strongly disagree. Bookmarking has not been replaced by solutions like Wallabag – the two rather supplement each other. I use bookmarks for "permanent" storage, and "solutions such as Wallabag" for temporary items – as Pocket's original name suggests: "Read it Later". So for me those are two different concepts which both have their specific use cases. I use both, and I'd warmly greet Wallabag integration to Nextcloud. But to repeat what I wrote in my previous comment: That issue you've linked concerning Wallabag was opened more than 4 years ago (about half a year later than this one here) – and as this issue here, I see it's still open.

Considering the choice of Nextcloud by the German government, hopefully these two tasks get some more weight (funding?) as well – as both are important. And while bookmarking might be an "old concept", it is far from being "replaced" or outaged. Remember: Eating is an "old concept" as well :wink:

[jancborchardt]

Sorry but this issue discussion is much too long and broad to be tackled. There are "Tags" in Bookmarks, which cater to the use-case of "group related Bookmarks together" which was mentioned in the original issue.

For any follow-up enhancements, please open new issues. And keep in mind it’s only few people (or one – @marcelklehr) working on it, so any help is welcome!

[IzzySoft]

@jancborchardt it got that long because the issue was opened more than 5 years ago and not solved since. I don't see how the request to have bookmark folders is too broad. What makes it broad are just the different approaches suggested. So do you want a separate issue for each of those? Because the requested feature is pretty clear, at least to me. And its being missing is why most of us asking for it here cannot really use ownCloud/Nextcloud bookmarks.

I understand that there's "just a little processing power" (as you wrote, just one person working on it). But I'm very disappointed that, after 5 years waiting, the issue simply gets closed with that argument.

[jancborchardt]

Again:

Sorry but this issue discussion is much too long and broad to be tackled. There are "Tags" in Bookmarks, which cater to the use-case of "group related Bookmarks together" which was mentioned in the original issue.

So it’s actually resolved. If there’s follow-ups → open separate issues.