Yes, this is giving away everything about your vehicles driving to a third party for sale or, manufacture. I don't like this personally and I don't like it for my vehicle either. Where I go in my vehicle and when I do it is my business. With vehicles being IoT connected, we are forced to surrender that data as there is no opt-out except for disconnecting the antenna. Not to mention going in to be serviced what kind of data is pulled off.
This is a combination problem poor default (listening to all interfaces?) and also IPv6 can be publicly accessible. It's a bit dependent on how this is configured upstream by default, but this is a gotcha compared to IPv4.
The article says no, the default is listening to just localhost. Given the instances in question have been deliberately configured to listen on public ports, calling this misconfiguration seems somewhat unjustified.
there are desktop builds https://grid.space/downloads.html that run entirely offline. you can also use the center menu to "install" it as a progressive web app.
It says 'local first' doesn't that mean you can run it locally after downloading? That's how I set up pianojacq, just so there aren't going to be a lot of disappointed people that lose their practice logs if I get hit by bus #9.
Because the traditional web is dying due to AI. Search is now turning into read the AI summary. So, what does the future look like? I mean, how do we bridge the gap between where we are now and that future. I don't like it...
Wireless is just fine for devices connected to the internet but as soon as you want to connect multiple devices to do a heavy load, backing up or those kinds of things, wireless really does still take a hit depending on access point density.
Definitely interested in the concept! Though it's not on the immediate roadmap.
A few thoughts:
- Obsidian's plugin system is JavaScript-based, which makes sense for Electron. For a native Rust app, we'd likely want something like WASM plugins or Lua scripting.
- v0.3.0 includes plans to extract the Mermaid renderer as a standalone crate and potentially the editor widget as a library — this modular architecture would be a foundation for future extensibility.
What kinds of plugins would you want? Knowing specific use cases would help prioritize. Custom renderers? File format converters? External tool integrations?
In the meantime, Ferrite has a "Live Pipeline" feature that lets you pipe JSON/YAML through shell commands (jq, yq, etc.) — not a full plugin system, but useful for custom transformations.
> Definitely interested in the concept! Though it's not on the immediate roadmap.
>
> A few thoughts: - Obsidian's plugin system is JavaScript-based, which makes sense for Electron. For a native Rust app, we'd likely want something like WASM plugins or Lua scripting. - v0.3.0 includes plans to extract the Mermaid renderer as a standalone crate and potentially the editor widget as a library — this modular architecture would be a foundation for future extensibility.
>
> What kinds of plugins would you want? Knowing specific use cases would help prioritize. Custom renderers? File format converters? External tool integrations?
>
> In the meantime, Ferrite has a "Live Pipeline" feature that lets you pipe JSON/YAML through shell commands (jq, yq, etc.) — not a full plugin system, but useful for custom transformations.
Personally, I think there's two plugins I would really want.
1. Peer-to-peer syncing of notes. I do hope there will be a mobile version someday of your app. Most of my quick jotting of notes happens on mobile and heavy editing happens on traditional laptop/desktop. It would be nice just to scan a QR code to pair up devices and away we go. Optionally a small binary to be the sync server for self host for hub and spoke design. I love Git integration, but we want to take this at a level for those that aren't technically inclined.
2. A robust API for tool integration. Being able to plug in external tools is super helpful for streamlining workflows. In addition I've used it to make accessibility tools integrate for command and control.
I do like the fact that Obsidian has vaults that are essentially separate profiles that have separate vaults location settings and plugins.
Mobile is definitely a long-term goal, the lightweight binary and native performance would translate well. Your QR-code pairing idea is elegant for non-technical users.
For sync, I've been thinking about:
- Git-based sync for power users (already have git integration)
- Simple local network sync (mDNS discovery, no cloud required)
- Optional relay server, as you described — small binary for hub-and-spoke
The plain-file approach (no proprietary format) makes this tractable since any sync tool works today (Syncthing, Dropbox, etc.). But a native, frictionless solution would be better.
2. Tool Integration API
This aligns with v0.3.0's direction. The plan is:
- Mermaid crate extraction, establishes the modular pattern
- Editor widget as library, opens up embedding
- Command palette / IPC, could expose operations to external tools
For accessibility specifically, what interfaces work well for you? Shell commands? Named pipes? JSON-RPC? Knowing your workflow would help prioritize.
3. Vaults/Profiles
Good point — workspace settings are currently per-folder (`.ferrite/`), but there's no concept of isolated plugin configurations per vault. Added to the consideration list.
"This gap closely resembles the broader gap between proprietary and open-weight models. This is unsurprising since nearly all leading Chinese models are open-weight, while frontier US models remain closed."
Open weights has nothing to do with why the U.S. is leading. That would imply the US is taking advantage to maintain their lead using at the very least, knowledge extracted from competitors open weights.
Still haven't figured out how to do Termux on Android with netbird ssh yet.
reply