@-mention support for “People” (identities)

Plugins ideas
1

A really awesome plugin would be an @-mention feature that works just like Tags, except it uses @ to link to a person or identity. # Tags are for topics; [[wiki]]-style links are an option but they don’t port over to almost any social media platform. There’s also apps like NotePlan 3 (see link, below) that work nicely in combination with Obsidian and which support the now-commonplace @name syntax.

Here are some use cases:

  • Distinguishing people (@KuraFire), topics (#tags), and pages ([[Hello, World]]) with clean designations for each;
  • Writing any kind of content wherein you refer to the same person or people multiple times;
  • Writing a book, especially fiction, where you have characters whose names may change;
  • Using your notes / vault for task management and tracking, calendaring, or really any kind of collaboration with other people.

Again, I know that this can technically be achieved with the wiki-style links (because they can be retroactively updated easily across the vault), but for some reason it just feels…dehumanizing to me to treat people (even fictional ones) as syntactically indistinguishable from page objects.

Also, an @-person in a vault of .md files does not necessarily need to be or have their own dedicated note or page, just like how #tags don’t necessarily have one.

Bonus: using a separate syntax for people would allow support for ye olde XFN :sparkling_heart: to be :partying_face:

36 Likes
2

I was about to post a feature request on this same topic. :star_struck::grinning::sweat_smile:

1 Like
3

I also want to add to this wishlist:
@someword should be actually a file. Infact both tag and file.
This way I can save or the app can enlist mentions. I may save contact information of a real person, some bio, where when I met etc.

4 Likes
4

So I was thinking about that. There is a case to be made for integrating @<person> links to some form of address book system, whether external app or an Obsidian plugin, but the simple way would probably be just doing what (I think) you’re saying: have them just be files like all other notes.

A nice contact card template could be quite useful, so a plugin like Daily Notes but for People would rock, especially if by itself it could add support for @.

1 Like
5

Would not a some kind of convention be enough? Say, #P_NameOfPerson? What would you gain by having a separate kind of tags for ppl? What am I missing?

6

I would love to see this functionality, but I think the dedicated page for them is crucial. I think they basically need to be treated as alternative #tag hierarchies. I wrote a bit about the rationale in here:

2 Likes
7

Having thought about it, I’m against this idea.

Markdown is already a rickety construction with different syntax options to produce the same effect and symbols with multiple possible effects. I feel that building on a house of cards makes it even more imperative for there to a strong and clear need for any divergence from “standard” markdown.

In Obsidian, we already have
[[ ]] wiki-links. But these have the advantage of much greater speed in use for a function that is key to Obsidian. And thus usage is shared with most apps in the PKM space. And there’s already an option to use markdown linking and a conversion to standard markdown gas been promised.
==highlights== An important function for editing and revising and making selected text stand out. It is not common in markdown, but some programs such as Typora use it.
#tags Not a standard feature, but some apps, such as Epsilon Notes, recognise it and it’s a key function for document management.

Obsidian is committed to be as interoperable as possible and the proposed @ syntax is very rarely used in markdown - the only example I’ve come across is the the Noteplan cited above (which is designed formeetingsetc and appears to be a database rather than using markdown files - and the actual functionality is identical to #. So I conclude that the size of the gain for most users doesn’t justify adding an extra item of syntax to markdown files.

Of course, plugin developers can do anything they want, and so long as it’s never incorporated into the main program it doesn’t bother me. If someone does a plugin for meetings, contacts etc, I can see that they might want to use it. Even so, I’d think it was better for the use to exist in something like a .json rather in the notes themselves.

7 Likes
8

I agree with you.

9

Your argument is reasonable, and yes a plugin would be suitable. But look we are used to @mentions like how we use #tags, so it can’t be justified as a divergent to practice.

3 Likes
10

It’s a divergence from markdown. Obsidian is attempting to follow markdown standards as much as possible.

1 Like
11

I get what you’re saying (and I agree), but I don’t understand how this functionality interferes with that goal.

Where are you getting that “interoperability” is a goal of obsidian? I dont think that’s necessarily true. I mean you rightfully point out [[wikilinks]] are not markdown. Obsidian is based on a universal format so that it can be stored by you and easily accessed anywhere for ever, but this doesnt mean that even all of the markdown functionality will be there in your new app. They guarantee the content.

The goal of obsidian if I understand correctly is to be future proof. And by interoperability they are referring to you being able to open and access your notes easily wherever you want, bc they’re yours forever in plaintext. Anything not standard to markdown (and obviously obsidian is much more than a markdown editor), including wikilinks, back links, graph view, may or may not be supported in your new app choice. This isn’t them failing their promise.

1 Like
12

Treating @ (people) as first-class citizens the same way that Obsidian treats links as first-class citizens seems like an obvious gain to me, but to expand on that:

  • using tags per your suggested solution is a hack and a workaround that doesn’t solve most of the utility needs
  • my initial arguments’ cases are not solved with a tag-hack solution
  • tags are for taxonomies; people are not taxonomies

(More use cases below.)

A great thing about Markdown is that it keeps working fine when the syntax is extended. Each of your three examples are extensions that don’t break anything, and two of them are unrelated to Markdown in the first place. Calling markdown a “rickety construction” and a “house of cards” is a rather harsh and inaccurate description for one of the more robust formats ever made.

More pertinently, the @-syntax does not break interoperability, and in fact it may even improve it. Twitter, Facebook, Messenger, Github, Reddit, Discourse (hey @Dor!) and so many other platforms use Markdown or “Markdown lite”—basic syntax without rich links or advanced features—and also support @-syntax for people.

A first class implementation of @ could conceivably offer the utility of flexible identity within Obsidian much like what Solid technology enables for internet identity at large: controlled identity representation. Example:

Input:              → output:
-------------------------------
@KuraFire:twitter   → @KuraFire
@KuraFire:firstname → Faruk
@KuraFire:nickname  → Supernova

(Imagine that the output of @KuraFire:twitter is @KuraFire.)

This would be a variation on the wiki link + heading combo, except generating output that doesn’t include the input, and doesn’t require the output to be provided in the input.

Example: using [[note#heading]] will include whatever key you use in the output. Similarly, using a pipe + custom label technique like [[person|nickname]] requires you to manually enter the output in your input, rather defeating the purpose of it -and- relying on intelligent auto-replace by the system any time you change the name.

6 Likes
13

You have a point but I’ve really thought about this more since my post 2 days ago and I actually think that we don’t need any kind of #tag or @people pages. theres a way better way to implement what myself and alot of other people’s use cases need for this and its way simpler: make folders color codeable.

Imagine having a “tags” folder or a “people” folder that you put each tag page or people page into. This is the same work as typing the “#tag” in the page. You can fully use the page to work out of all you want, and best of all, since the name is ‘pure’ (doesn’t have any prefixes), all of your linked and unlinked mentions properly function.

Now, when you want to see a list of people you just Cmd+O for the quick switcher, type “People/” and a list of all the people in your vault populates. When you want to see a list of your tag pages (or anchor pages), type “Tags/”. I’ve already started doing this.

Finally, to give the visual distinction in graph view, if you make these folders color-codeable your set up is OP. No need for messy prefixes, no need for special tags or extra first class variables.

Got this idea from @Picard here: Graph View: Colored clusters - #13 by Picard

This is still a “folder-free” hierarchy, bc your notes don’t gain structure from the folders. The folders just group certain page types together; the hierarchy of the vault is still completely flat. I’ve also been able to get rid of most of my tags, which is awesome. Traditional folders and tags are imo just crutches until the notes can be properly linked to each other and to map pages

This is the feature request I’m talking about. Sorry if I’m side-tracking the convo, but I’m linking it here bc I really believe this would solve this use case.

5 Likes
15

I just wanted to mention that this would conflict directly with the citation syntax used by pandoc. From their docs:

Citations go inside square brackets and are separated by semicolons. Each citation must have a key, composed of ‘@’ + the citation identifier from the database, and may optionally have a prefix, a locator, and a suffix. The citation key must begin with a letter, digit, or _, and may contain alphanumerics, _, and internal punctuation characters (:.#$%&-+?<>~/). Here are some examples:

Blah blah [see @doe99, pp. 33-35; also @smith04, chap. 1].

Blah blah [@doe99, pp. 33-35, 38-39 and *passim*].

Blah blah [@smith04; @doe99].
2 Likes
16

This is a good point! I definitely do not want to lose pandoc citations. I have completely forgot about this, even though I use those on a daily basis…

1 Like
17

@argentum, I’m not sure I find this a compelling argument against an optional plugin, since that proves my point of its utility more than it causes conflict with it.

Pandoc’s @-syntax references a database ID key, either a person or a work (often the work by a person, referenced as the person). Since Obsidian doesn’t use a database system behind it, you’re talking about a use case of using Obsidian’s output in a completely different system and context, which I would consider very much second-class use rather than first-class use (Obsidian itself).

Additionally, the pandoc and @-person cases won’t conflict unless you happen to have a person with the exact same name as a database ID key, but if so, that’s easily resolveable—give the person in the Obsidian vault a slightly different name, since it’s self-contained by design, whereas use of pandoc is not (it may be locally used, but again: database, not Obsidian, so not fully self-contained).

Lastly, if someone is a heavy pandoc user and find that all their database keys match the names of people they want to reference by the same shorthand (for some reason), they could just not enable this plugin, or not create the Person pages. Really solves this edge case problem entirely.

4 Likes
18

@ishgunacar: What is the “messy prefix” you keep mentioning?

Several billion people use @person and #hashtags, far fewer use the imo much messier [[wiki]] syntax. Use of both @ and # long predate wikis, and are far more entrenched and accessible concepts.

Your proposed workaround is decent, and we can already use notes in folders that way yes. However, it does require ‘hacking’ the way Obsidian works and doesn’t solve the name variations or updates problem. You’re still relying on the less-accessible [[wiki]]-style syntax and it doesn’t transfer to any other platforms the way #hashtags and @people do.

I wrote up a more example-y version of my proposal in Obsidian itself to demonstrate my points:

Screen Shot 2020-10-07 at 3.54.54 PM
Screen Shot 2020-10-07 at 3.54.54 PM700×1197 132 KB
Screen Shot 2020-10-07 at 3.55.12 PM
Screen Shot 2020-10-07 at 3.55.12 PM756×1363 129 KB

3 Likes
19

The problem with any kind of prefix is that in order to harness the full backlink power of obsidian you would have to always use that prefix when referring to any thing of that type, even when they’re not important yet, which seems silly and not to mention unnatural and requires intention. One of the biggest advantages of using a digital tool is the ability to spontaneously rediscover notes. This (or any type of prefix) effectively kills that.

Here’s what I mean:
Let’s say I’m super interested in Socrates and have been researching his works a lot lately. I make a @Socrates page as a hub, and reference @Socrates in my notes. This is great.

But it turns out, I actually had a mini Socrates binge last year. And on top of that I used to research Plato’s works a lot, and a lot of my notes on Plato reference Socrates. BUT at that point, he was just a supporting character, and I didn’t really care about him much. All of my references in those notes are along the lines of “@Plato and Socrates loved to go fishing.” Socrates wasn’t cool enough for a prefix yet.

When I make my new @Socrates page, my new @ page does not pick up on any of those notes, since my unlinked mentions are searching for instances of ‘@Socrates’, not ‘Socrates’. The same thing goes if politics suddenly piques my interest and I create a MOC_Politics; I don’t automatically see any of my old notes from, for example, 2 years ago where I my research in economics intersected with politics a bit.

However, with my system, you do. If I create a Socrates.md file next year and put it in my People folder (I think of them not as folders but more as bags, as they’re not heirarchical, but purely unorganized bags of things that are like in essence), my unlinked mentions will automatically suggest the times last year where my Plato notes mentioned Socrates. When I create a Economics.md file, my unlinked mentions automatically pull up that random economics book that piqued my interest last year and any notes that intersected economics. No searching, no digging.

The same thing goes with tags. I’ve almost completely done away with tags except for deliberate and actionable ones (#important, #unfinished, #readlater). Any topic worth “tagging” has its own map page. And–when I create a new map page (that I would have made a tag for in the past) that piques my interest, I suddenly have all of the unlinked mentions of where my old notes intersected this ‘tag’. I want to focus on taking notes, not organize them. After all, we’re all here to take as many notes as possible, while losing as few as possible, with as little manual sorting as possible.

Again: the power in tools like obsidian is not just that they let you link things deliberately, its that they help you link things you never even thought of. Using prefixes kills that.

Edit:
I realized that I didn’t answer your point about aliasing. I think doing it this way, and then still putting YAML data for aliases (so that references don’t create duplicate non-canons like you mentioned) would be truly OP.

Also just realized you might be Turkish. Merhaba bende turkum:)

1 Like
20

Very Well defended, I couldn’t have justified this ‘plugin’ request like you.

21

I was thinking that @mention will work same as [[mention]], just instead of applying square brackets I will prefix a symbol @ …

And therefore it will create those files like mention.md under-the-hood.

2 Likes