nicknames-cache

This article is a stub. You can help the IndieWeb wiki by expanding it.

A nicknames cache is a way indieweb sites store information about people to improve the user experience of the site owner referring, mention, and/or linking to those people.

Use Cases

Easier Person References When Writing

When creating a post, being able to type merely a given-name, or @-handle, or even domain name that represents a person, and have your site automatically both autosuggest while typing, autocomplete, and convert that reference:

on your post on your site: a mini-h-card hyperlinking the person's full name to their domain
- or perhaps the person's given-name inside an abbr element which has the full name
in a POSSE copy
- on Twitter: the corresponding @-name for that person (per Twitter#POSSE_to_Twitter step 4. translate indiewebsite people references)
- on Facebook: the corresponding profile-link (person-tag) reference for that person

Better Person Name Display

When displaying a reply-context or a comment or other interaction (likes, reposts) e.g. in a facepile, it's better to:

Retrieve the name of the referring person from a nickname cache

Rather than have to:

Retrieve the name dynamically from an h-card on that person's site
- disadvantage: slower, less responsive, more code
Retrieve the name from your own storage of the reply / interaction
- disadvantage: refers to people by their old name, which they may have changed for any number of reasons, personal, relationship or otherwise.

Better Person Icon Display

When displaying a reply-context or a comment or other interaction (likes, reposts) e.g. in a facepile, it may be better to:

Retrieve the icon of the referring person from a nickname cache

Rather than have to:

Retrieve the icon URL dynamically from an h-card on that person's site
- disadvantage: slower, less responsive, more code
Retrieve the icon URL from your own storage of the reply / interaction
- disadvantage: less reliable, icon URLs change

Alternatively, it may be better to:

Retrieve the icon image itself from your own storage of the reply / interaction
- advantage: shows the icon that the person was using as of the time of the post!
  "… the idea that an avatar at the moment of a Tweet should be considered a part of that Tweet is also valid and interesting.
  [1]
  "… screenshots, which do preserve that context,it makes sense"
  [2]
- disadvantage: storage space: requires copying and storing likely many duplicate copies of the same icons of people for every such reply / interaction
- disadvantage: showing a dated/old icon of the person (one they may no longer want to publish)

Connecting Authors As One

When displaying sequential like posts, it may be possible to (further) cluster them if it can be determined that they were made by the same person, even if across different sites (their own site, different silo accounts etc.), by looking up their different author URLs in a nicknames cache and determining that they're all the same person.

See like#Brainstorming, specifically, "With authorship knowledge, [...]".

IndieWeb Examples

Add yourself!

...

Past Examples

Kyle Mahan

⚠️ Kyle's site is now unfortunately a zombie site, so links have been replaced with archived versions where available

Used Red Wind's Contacts in posts to show sparkline icon and full name of person hyperlinked to their website, and @-names in POSSE tweet copy, e.g.:

archived example
POSSE copy: https://twitter.com/kyle_wm/status/483972403169460224

Storage Model

Typically a flat list of items at least with:

person full name
shortname / given-name (what the author of a post would type to refer to the person)
domain name
@-name
icon URL

And potentially also:

other profile URLs or userids on silos you POSSE to (e.g. Facebook)

Discussion

How do we get the information into the cache? [3]

Refresh rate

How often would you recommend a nicknames cache goes and refetches the cached person’s h-card? Someone who is going through a name change would want this to be picked up quickly. Or if you are caching their profile photo you might now be representing them with an image they no longer identify with.

On that note: would you expect someone to bust your cache by changing the URL of their photo?

Jacky Alciné 19 April 2019: I'm using the Cache-Control header on provided sites to determine this. Or every week.

Brainstorming

It might also be useful to store the status of the last webmention sent to the url associated with the nickname. Then the UI associated with the nickname cache can reflect the "reachability" of each user (ie the likelihood that they received a notification of their nickname being mentioned).

Possibly store incoming webmentions (outgoing?) automatically to the cache.