kepano

The rows are individual Markdown files and the columns are YAML frontmatter properties in those files.

There are some special properties prefixed by `file.` which are implicit to the file itself, e.g.`file.name` refers to the file name, and `file.ext` is the extension.

The base views are defined as YAML in .base files or can be embedded in code blocks within a Markdown file. You can also export the rendered views to a Markdown table or CSV.

See also: https://help.obsidian.md/bases/syntax

You can embed a base in a canvas, and you can list canvases in a base.

You can import all the underlying data from Notion using the Obsidian Importer plugin, however I believe that Notion's Databases export only includes a CSV. So you'll need to recreate the views to be able to interact with them dynamically.

https://help.obsidian.md/import/notion

It's on the roadmap, yes. https://obsidian.md/roadmap/

I understand you're trying to be more precise, but what the average person cares about is whether the knife rusts easily or not.

I don't think the average person is going to understand what you mean by "immutable properties after measurement", though I'll concede "self-guaranteeing" is probably equally confusing.

"Verifiable and non-reversible" seems clear enough, but a bit long.

> The promise that Obsidian will always use markdown isn’t self-guaranteeing.

True, but Obsidian doesn't make that promise. The promise is "file over app": you control the files you create. In this way the promise is not reversible, and self-verifiable.

"...will always use markdown" is not something any app can guarantee. At best an open source app can guarantee it for a specific version (assuming it doesn't require a connection, or the user can self-host the server).

Not all materials are a good example of a self-guaranteeing promise because purity can't always be easily verified at home without special equipment.

In the example of stainless steel it is "stainlessness" that is the promise, and that only requires water to test.

Simply, it is an unpolished thought. It gives coworkers a lens into what you're thinking and gives space for ideas that are not fully baked.

If you're going to leave Substack, don't just get on another platform where you don't control your content. Learn how to set up a static site with RSS, on your own domain that you can easily move to another host.

FWIW it's not something I asked anyone to do. The practice started organically and continues to exist because everyone created their own channel and kept going with it.

One thing I suggested was that they should be muted by default so that they aren't a distraction and don't set the expectation that they should be read.

I thought it would be interesting to write about because it was an emergent practice that seems to be sticky and useful within our team.

In practice 2-10 individual channels with 1-3 posts per week has less overhead than one off-topic channel with 30 posts because there's less mystery meat. It reduces the "am I missing something important?" feeling.

We do also have an off-topic channel but on our team the individual rambling channels get more posts. Maybe because it's less likely to derail an existing conversation and allows more continuity with each person's thoughts.

> Assigned channels where you are expected to post your random thoughts feels utterly dystopian to me.

I agree that if it becomes a top-down expectation or a performance metric it would be terrible. The practice at Obsidian was emergent and bottom-up. Maybe that's because of the small team size and flat structure. Also why the article states "They should be muted by default, with no expectation that anyone else will read them."

In what way did smartphones replace laptops?

That's pretty much the conclusion of my article linked above, at least short term. When I worked on that AR device we experimented with a segmented electrochromic layer that could allow a mixture of see-through and pass-through, but it's far from mass-producible, and probably a dead-end approach for what Apple is trying to do.

I agree with your core sentiment but unfortunately we don't have a mass-producible display technology that allows for black pixels in a see-through optic (yet). It's going to be really hard to achieve.

Pass-through is the only AR approach that currently allows black pixels, but it has uncomfortable limitations compared to a see-through optic.

https://stephango.com/black-pixels

Currently I am relying on manual testing and user feedback, but yes, I'd like to add tests.

Defuddle works quite differently from Readability. Readability tends to be overly conservative and tends to remove useful content because it tests blocks to find the beginning and end of the "main" content.

Defuddle is able to run multiple passes and detect if it returned no content to try and expand its results. It also uses a greater variety of techniques to clean the content — for example, by using a page's mobile styles to detect content that can be hidden.

Lastly, Defuddle is not only extracting the content but also standardizing the output (which Readability doesn't do). For example footnotes and code blocks all aim to output a single format, whereas Readability keeps the original DOM intact.

Feel free to help :)

No it's all rules-based. I think the code you're referring to is "extractors", which are website-specific rules that I'm working on to standardize the output from sites with comments threads (e.g. HN, Reddit) and conversational chats (ChatGPT, Claude, Gemini).

Are there any in particular you can recommend?

The input is there to test the url option — which I admit is a bit confusing, so I have removed it for now. I haven't found a good and free way to proxy requests from a GitHub page (yet).

Since the content is saved to Markdown you can use it with pretty much any tool that will ingest that content.

There's also Obsidian Web Clipper's Interpreter feature, which lets you run prompts on a web page before saving:

https://help.obsidian.md/web-clipper/interpreter

Obsidian cannot access your notes even if you use the Sync service (it's end-to-end encrypted)

I built Obsidian Web Clipper (open source, MIT) to replace my read-it-later app and save everything to local markdown files. Now that Obsidian Bases is available, it makes for a very nice web archival tool and reading experience. Here's a video:

https://mastodon.social/@kepano/114553164915046938

You can use Web Clipper with any app that supports Markdown, not just Obsidian.

Defuddle is the underlying HTML-to-Markdown library I made for Web Clipper, and can also be used as a CLI:

https://github.com/kepano/defuddle

https://github.com/kepano/defuddle-cli

Obsidian Web Clipper is available on all mobile browsers that support extensions including Safari, Firefox, and some forks of Chrome

I had a similar though a while ago[1]:

> the most salient quality of language models is their ability to be infinitely patient > humans have low tolerance when dealing with someone who changes their mind often, or needs something explained twenty different ways

Something I enjoy when working with language models is the ability to completely abandon days of work because I realize I am on the wrong track. This is difficult to do with humans because of the social element of sunk cost fallacy — it can be hard to let go of the work we invested our own time into.

[1] https://x.com/kepano/status/1842274557559816194

If Obsidian didn't allow people to store files in the device storage it would be accused of forcing people to use the paid first-party Sync. Offering both options lets people make the choice that's better for them.

Joplin uses its own database, it can't edit Markdown files.

The primary reason it's recommended is that it provides more freedom and interoperability. Read this thread and you'll notice that many people sync their notes using Syncthing. You cannot use Syncthing with app storage because the files are sandboxed. Many people enjoy the freedom of being able to read/modify notes using multiple apps.

The secondary reason is related to user expectations and file deletion. The device storage option behaves more like desktop in that if you delete Obsidian your files will not be deleted.

For people who are okay with the tradeoffs, app storage is now an option. That's a good thing, no?

Not anymore. As of Obsidian 1.8.10 you can use app storage which doesn't require additional permissions. It's explained here:

https://help.obsidian.md/android

As of Obsidian 1.8.10 on Android you can choose to store your notes in the sandboxed app storage which means other apps can't access those files.