Hi Jean Louis,
seeing a link like a mere pointer looks like a very interesting idea, thx for sharing it! Let's maybe not flood the conversation, I think I got your point :) I didnt think of the niceties that databases offer so far, but that looks useful indeed. Let me explain what kind of link-based workflow I have in mind before saying what system is best suited. My main focus is to make links reliable, in the sense that when you follow a link, it always just works; in linkin-org, this is ensured with a decentralized id system etc, but that's irrelevant for the current matter (check out https://github.com/Judafa/linkin-org to know more). >From the user's point of view, it should feel as if you merged org-mode with >dired as your links (with file type) are access points as reliable as a file >listed in dired. For a link (with file type) to work, you just need two things: the link and the file. Makes sense, trivial, and that's meant to be this way. By extension, I see any third-party, centralized intermediary as a weakness towards reliable links. Correct me if I'm wrong, but in case the database is lost/corrupted/non-updated, then the links may not work anymore. And this would be the worst outcome: you're left with years of notes full of links that are now useless. I'm primarily targeting a fully decentralized system, which fits best with the philosophy of org mode imo. This comes with a whole bunch of desirable niceties: you can move/update your linked file anywhere (dropbox app on your phone, whatever) without notifying a database, the link still works. But BTW, nothing prevents from using both systems at the same time, as in the end you just want to create an org-element. I would say it may even combine neatly: one can use the id of a file in last resort to make sure the database cannot lose track of the file. Julien PS: Some more minor remarks: - > Link creation or capturing should be instant. 1-3 seconds. The link is created automatically, obviously. - with a database, no easy way to share a data afaict. Otoh if the metadata is inside the link, then that's as simple as paste the link, put the file in attachement, send the email. "Jean Louis" <[email protected]> writes: > * Julien Dallot <[email protected]> [2026-06-21 12:53]: >> > I mostly agree with your summary. Unfortunately I do not have a roadmap >> > with actionable steps. >> Without talking about adding this to the org's code base, I would be already >> happy that we agree on main guidelines for metadata in links, or at least >> narrow down possibilities. >> As I mentioned, I am the author of a package that proposes to build a whole >> workflow on org links, so having feedback on link format/use cases is >> already valuable. >> Hence if there emerges here a format that makes sense and that gathers >> support, I will anyway implement it; thus getting more feedback to >> ultimately add it to org mode, hopefully. >> >> Let's maybe first discuss what we want for a "degree of compatibility" with >> web links. >> I see 3 degrees: >> 1. whenever possible, the link should directly work when pasted into the url >> bar (after removing the surrounding [[]] of course) >> 2. pasting the link into url bar doesnt work. But, whenever possible, there >> should be a "trivial" way to convert org links into web links. >> I'm thinking of the following. use plists to store metadata, but: >> - name the plist's properties with the same keywords as in web links (use >> :text for searching string, use :highlight to highlight a given pdf region, >> etc) >> - come up with a systematic way to convert structures, ie, (1 2 3 4) >> becomes 1,2,3,4 (as needed for the edges of the region to highlight) >> Not sure this can be done in a systematic way for other use cases, but >> this is merely a guideline idea for now. >> - during the conversion process, remove any emacs-specific keyword that >> would make the web link crash >> etc >> 3. not care at all about web links and stay inside emacs. >> >> Given your comment on legacy format >> >> Notice that the links above do not come with the usual separator "::". >> > >> > Yes, and Org should treat links in a backward compatible way somehow. >> I would say the second option looks best. >> Having a separator "::" would make the link unrecognized by firefox anyway, >> so why not make it more readable as well then. > > Putting metadata into link is wrong. Subject is about arbitrary > metadata in org links. > > Your Three Options > ------------------ > > 1. Full web compatibility — the link works when pasted into a browser > 2. Partial web compatibility — the link contains plists that can be > translated to web syntax > 3. No web compatibility — the link is Emacs-only > > Option 1 is dead. You already proved it yourself: custom keywords > break the fragment directive. Region highlighting is not > supported. The web standard does not allow arbitrary metadata in the > URL. > > Option 2 is where we are now. Plists in the link. ::(:page 12 :edges > (0.240196 ...)). It works inside Emacs. It can be translated to web > syntax for export (stripping Emacs-specific keywords). It is > human-readable. It is extensible. > > Option 3 is where Org currently is: > [[pdf:file.pdf::page=12]]. Limited. Not extensible. No arbitrary > metadata. > > Option 2 looks the best but is compromise. The correct approach is not > Option 1, 2, or 3. It is Option 4: the link is just an identifier. The > metadata is in the database. > > [[id:127190][Ali Cook - Snake Goddess]] > > or use UUID, or any other identifier. You do not even need the name, > as Org could be made to read the name from the ID or UUID if name not > specified. > > Everything else—the page number, the coordinates, the highlight, the > timestamp, the relationships, the tags, the type, the subtype, the > author, the date, the version, the viewer preference—lives in > PostgreSQL.
