Nownownownow.now a lexicon for /now

Lexicon Community
1

Hey folks! I am the proud owner of the domain nownownownow.now. My intent is to define a lexicon for publishing /now updates on protocol. If you aren’t familiar, sive.rs created about nownownow.com, an indieweb slashpage for sharing what you are up to nowadays. I have a non-schema-validated record on my PDS now, which powers my /now page on tynanpurdy.com/now.

I figure this will be a simple lexicon. A now.nownownownow.entry constitutes a createdAt, langs, and content. The content I propose should use the https://markpub.at/ lexicon so that folks can use good ol’ markdown to write their updates. I have decorated my /now page with additional content like the books I’m reading and my last few teal scrobbles, but I think those can live outside the .entry body.

Requests: a co-lead for this Lexicon Community Working Group, and feedback on the schema definition.

See my stub at the lexicon definition below.

{
  "lexicon": 1,
  "id": "now.nownownownow.entry",
  "description": "A /now entry containing current activities and thoughts",
  "defs": {
    "main": {
      "type": "record",
      "key": "tid",
      "record": {
        "type": "object",
        "required": ["createdAt", "content"],
        "properties": {
          "content": {
            "type": "union",
            "description": "Rich markdown content using the markpub lexicon",
            "closed": false,
            "refs": ["at.markpub.markdown"]
          },
          "langs": {
            "type": "array",
            "description": "Optional ISO 639 language codes (e.g., 'en', 'en-US', 'zh-Hans') identifying the language(s) of this entry",
            "items": {
              "type": "string",
              "minLength": 2,
              "maxLength": 10
            },
            "minItems": 1,
            "maxItems": 10
          },
          "createdAt": {
            "type": "string",
            "format": "date-time",
            "description": "ISO 8601 timestamp when this entry was created"
          }
        }
      }
    }
  }
}
7 Likes
2

If we can get @sive.rs into the discussion, I would also be happy for it to live on the nownownow.com namespace.

3

What about other https://slashpages.net

3 Likes
4

I’m open to it. /now came to mind since Derek already aggregates the entries on nownownow.com which, done Atmospherically, would be far more powerful.

5

Reminds me of the South African phrase “now now” :sweat_smile:

6

Oh yes! It’s been a while since I discovered the now pages, and they are awesome. Making it a lexicon with markdown is nice. Incredible domain purchase btw.

7

Derek was having some issues with the discourse signup and offered that I reshare his reply to my email here.

I’m the kind of nerd that loves this stuff, runs my own PDS (did:plc:6g7vq7yio6k5emgj4pykat4l), and writes my own code by hand.

But I’m also the guy that’s run nownownow.com for 11 years - see The /now page movement | Derek Sivers for the cute beginning. There are 4077 entries as of today, and I added each of them by hand after receiving a personal email from the site owner, so I’ve got a sense for the kind of people that have a /now page.

Most are not super-technical. Most just have a site made by WordPress or BearBlog.dev or Wix or Hugo or whatever. Some use HTML, but many use the fully-JS style, or whatever their site-making-tool did for them. Those that do nerd-out tend to do so in esoteric ways. Live pages generated from API feeds from their social media, or whatever. I’d say no two are alike, but those that are the most conformant are usually the least technical.

Also, most people seem to create their /now page once, when they have time on their hands, then leave it to rot as their optimistic plans hit real life. I delete a few dead links every month.

So you can guess where I’m going with this. If you’re suggesting that everyone with a /now page implement a standard thing on their site, I agree it’s a beautiful idea, but I’ll bet very few would do it, and many of those that do would just be serving a static representation of a years-expired status.

On the other hand, if you’re asking me to play parser, to input the variety of web formats people submit, and normalize it into some standard feed, I’d be up for that. See New /now pages and https://nownownow.com/nownownow.txt - but I’m not sure how useful that would be to anyone.

Anyone here, feel free to email me at https://sive.rs/contact (Sorry that’s still the only inbox I check.)

- Derek

I think all of that is reasonable. A now page on a website is the type of thing structurally inclined to be left unupdated for years. This, I believe, is where the Atmosphere can shine. Once you put the updates on the Atmosphere, their creation, updates, display, and aggregation become commoditized. Any app or website can be a place to read /now entries. Any app or website can be a place to update your /now with a new entry. Anyone can easily create an aggregation and novel experience on top of /now entries across the Atmosphere, only as much of the hand curation of the current index as desired. Putting /now entries on the protocol can save it from being a forgotten corner of a website you haven’t touched in years.

Building support for rendering atmospheric now entries on your website will take some additional effort over the status quo. I would say that effort is easily overcome. One could foresee a web component which takes a DID parameter and renders in plain HTML the latest /now entry from that account, inheriting the styles of whatever website it is placed in. That is an easy, one time paste into an editor, regardless of your website tooling. Additional helpers and modules are open for anyone to create.

On another note, I do recognize there is a potentially much simpler approach to achieve ultimately a similar or complete parity solution: use a standard site publication. A /now entry is effectively a blog post, with your history of /now entries effectively being a blog publication. You could detect which publications are /now logs by their canonical url, since a standard site publication can in fact be a subpath. Boom, simply create a publication with a canonical URL ending in "/now" and you’ve got an Atmospheric /now page. The main drawback I see with this approach is that it is not as easily interoperable for other clients and writers to create /now logs or add entries to them. Aggregation would still be doable, albeit with a little more direction than a simple NSID target.

2 Likes
8

Hey, I do have my own /now page and looking at Derek’s response, maybe I am one of the few that would actually be up for implementing something like this… But honestly, I’m not sure I see the use-case :sweat_smile:.

I already have an RSS feed for my /now page, so anyone who wants to subscribe to it, can do it. And I also post on bluesky (and Mastodon, and X) from time to time about these updates, so whoever is following me there will also get them.

What would be the benefit to implement this with ATProto? Who would be able to get my updates that is not getting them already? Part of the problem, I think, is that this seems like a pain to implement. I guess I’d have to connect to my PDS through an API, and every time I post an update create a record or something? With the current architecture of my website (basically, a bunch of markdowns with a created_at date), I don’t think it’s super easy to automate something like that. The only reason I have an RSS feed is that I don’t have to reactively perform any action, I just build a feed with all the updates sorted by date. But all the information still lives in the markdowns.

9

The benefit would be surface area. Right now I can only read those updates by visiting your website, and only grab that feed if I know about it and fetch it from your website. Making it atmospheric makes it much easier for any app to show your /now next to your profile and identity in a push-based relationship rather than pull. I could easily backfill every /now update in the whole network with any of several tools and packages without having to know about all those sites proactively.

1 Like
10

Data point from my own https://gui.do/now/, which kind of proves both Derek’s and Tynan’s points:

Top half is a hand-written focus statement that currently says “Updated 21 June 2026”… so yeah, three months already. Bottom half is live and pulled from my own atproto data: an activity feed across apps (via Sifa ID), what I’m reading from Bookhive and latest Grain pictures. That second half never goes stale, but the bit I have to write myself rots….

So +1 on keeping books/scrobbles out of the entry @tynanpurdy.com, keep it to the authored part and let readers compose the rest from lexicons that already exist.

Same goes for “current” stuff btw. Sifa profile records (position, project, involvement etc.) have a startedAt + optional endedAt (“omit if ongoing”) and several have an isPrimary flag, so the more formal current role and active projects are already public and a /now renderer could just list them. The informal stuff like “learning Spanish” or “my thoughts on X lately” doesn’t really belong on a professional profile though, and imho that’s exactly the gap .entry can fill here.

Few schema suggestions:

  1. an optional url pointing to the /now page on the web, plus a <link rel="..."> on that page pointing back to the DID or record (afaik similar to what standard.site does for documents). The record → site direction lets apps link to the web version, the site → record direction lets a directory like nownownow.com detect these automatically instead of adding them by hand. And together they verify the site owner actually published that record.
  2. optional short plain-text summary, because a profile card next to someone’s handle wants a one-liner and not a markdown parser
  3. optional updatedAt, otherwise with tid keys every typo fix is a new entry

Staleness you then get for free: an aggregator can hide or flag anything older than X months based on createdAt/updatedAt, which could automate the monthly dead-link cleanup Derek now does by hand.

@noeldemartin.com re the markdown setup: +1 on keeping the site as the source of truth, I don’t want my PDS to be the only home for things I write either. But imho that doesn’t have to be a pain, a build/CI step can publish the latest entry as a record whenever the markdown changes (with OAuth). Same idea as your RSS feed being generated and in theory zero extra work per update. I think it would be good if the users can choose their source of truth (with standard.site you can also set it up like that).

2 Likes
11

good calls. at that point, this becomes so similar to standard site though that I would almost prefer to use actual standard site. You could query the network for publications who’s canonical url are “[handle]/now” and there you go. Gives people the flexibility of choosing different content schemas and all the niceties of standard site.