Show HN: Espial: an open-source, web-based bookmarking server
github.com
github.com
Does your project offer any advantage over the obvious competitor, apart from being open-source/self-hosted?
Shameless plug: I have also written a bookmarking app[0], which goes a different route: I like to manage my bookmarks in plain text files instead of collecting thousands of links I probably won't ever get to see again.
[0] - https://staticmarks.com/
When you have over 67,000 bookmarks, as i do, I feel open-source/self-hosted becomes a higher priority due to for data ownership and performance reasons.
By moving to self-hosted, i was able to bring down my "cold-start"/"non-cached" wait time on tag filters from 30s to ~1s.
> I like to manage my bookmarks in plain text files
I think that's a great idea and definitely see the value in going that route.
Obviously, it's a different place in the design place. Hosting & deployment is much easier of course. Though workflow for adding new bookmarks seems more manual e.g. can you add new marks while on your mobile phone, quickly?
My use case may be a bit different, as i add marks as part of browsing for things i want to return to later in the day, and also for long-term recall or aggregation when researching a topic, with as low/minimal-effort as possible
I think highlighting the good performance is worth mentioning on your project's page (maybe with some stats).
> Obviously, it's a different place in the design place. Hosting & deployment is much easier of course. Though workflow for adding new bookmarks seems more manual e.g. can you add new marks while on your mobile phone, quickly?
This is exactly the reason why I did not write an easier way to add the bookmarks other than editing a text file. Because I don't want to end up having 67.000 bookmarks. I have an "inbox" folder in my browser where I put all the stuff I think is interesting. I later review them and either 1.) turn them into an actionable task in my todo manager 2.) delete them after finding out it's really not that interesting (most of them) or 3.) put it in my bookmarks file if I think this is something worth archiving. The last one does not happen very often, though.
As you said, this is a much different use case than yours. I get how most people go your route, but it does not work for me. It encourages my fear of missing out: "oh, this is an article about XXX. let's archive it for later". But if I ever decide I want to learn about XXX, the article might be outdated and I might as well just search for a new up-to-date source (especially being a frontend developer, where yesterday's info is already outdated). However, I can see how such a system really shines when doing research.
AFAICT most folks don't have more than a couple thousand at the high end, so they probably don't run into these perf issues — although it was my motivation, it's probably not relevant to them.
Also, I totally get how your workflow makes sense—especially for fast-moving topics like FE dev, where there may be more value in just doing a new google search/source.
I also really like tagging over hierarchy. Again just highlights the different use cases we have. If i get really crazy, I might try experimenting with more interesting tagging methods or apply some ML techniques.)
Still, re-using the filesystem is very clever idea, and has a bunch of advantages, not discussed yet.