I do use it, on Desktop only. On mobile I still use Pocket only.
Actually I use an Obsidian plugin to sync my Pocket saves into Obsidian.
That plugin might be a great backup/way-out strategy for Pocket users.
I use it pretty extensively. Aside from being a pretty poor experience on mobile (it straight up can't be used on iOS at all, works ok on Android), it's the best web clipper I've used.
I really wish they would integrate the functionality into Obsidian itself, though I think there are technical limitations with it.
You can do this by picking a VPN provider that supports WireGuard. In WireGuard config file, you can change the dns address to pihole. I did this so that I can use VPN + nextdns together in iOS because I can't change DNS in iOS.
I worry this is a start for a toolchain monopoly, I don't like the idea of all-in-one, how can a single toolchain be the best of all fields? Will it suppress innovation like jslint -> jshint -> eslint? Just because the new and better tool is not part of the toolchain!
In the Java world 99% of the code is compiled with javac.
In the .NET world 99% of the code is compiled with csc (or whatever it's called, don't remember that well)
In the C world, with one of the biggest ecosystems and a fragmented history going back half a century, 99% of the code is compiled with GCC/Clang/VS CL (of which VS CL is there just because Microsoft insists on it being there).
Similar things happen with interpreters, CPython, Yarv, etc.
Javascript should innovate at higher levels. And it should have a linker and tree shaking compiler as default for every project, everywhere, so that people can stop making silly small libs and instead can use big ones that get compiled to small code bits that are distributed by websites.
Until that level takes the problem of in-browser, persistent file/blob storage seriously, the JS ecosystem will not be able to truly progress, particularly when it comes to the question of linking evolving code bases with more stable libraries. But I digress. (I'm not going to "pimp" for my project now... see my comments!)
Having a good sensible default is one thing, bundling everything together is another. If I prefer jest over the test suite provided by Rome, I would have to install two test suites in the same project. Why not split them into different packages and let user pick what they want?
depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
I mean they're not supported OOB but you're just describing a session cookie with some signed metadata. If "the ecosystem" and interoperability with existing services is the goal then has the advantage.
If you're talking about something bespoke then it probably doesn't.
Delegation via JWT replay downstream? Maybe, I guess, if those other services all have the same "aud(ience)" requirements, or don't bother checking audience. Probably not a design to hang one's hat on.
That's precisely the use case for JWT I recently had to work with, where cookies are irrelevant.
The web server gets a token from the API server, then prepares a few JSON messages that the web client will send asynchronously with JS. Since each message content is signed, the web client can't tamper with what is sent to the API. JWT was perfect for this 3-tiers messaging.
I mean is all this complexity really worth "I can send data to an untrusted client so that it can later send it back to me?" compared to just storing that data somewhere like Redis?
Then you have to provide a consistent view of the database across all server nodes, and the database updates need to propagate to all of your servers more quickly than the clients can issue requests. How complex is JWT compared to that?
