A shared lexicon for *video notes*? Looking for input before I build

Lexicon Community
1

I’m considering tobuild an app for recording short screen videos and sharing them as video notes. Basically Loom for AT.

I’d love your input on the lexicon shape before I settle it.

The use case

You record your screen (a window, a region or the whole display) with your voice and an optional webcam bubble, and share it as a quick explanation, similar to post-it notes or voice memos.

I see two main user groups: people working together who might send each other video notes (a bug walkthrough, design feedback, a project handover), and educator creators sharing clips with their audience (tutorials, top tips…).

Why a separate lexicon?

These are informal notes, quick to make, and often disposable. They should not appear in the Bluesky video tab, in Bluescreen, or in any other app built for “finished” videos. Promoting a video note to a bsky (or wherever) post is of course possible, but it’s a separate explicit action.

Visibility

Public or unlisted first, private later. Unlisted only means the user’s profile does not list it, because ofc repo data is public. Real private notes will need Spaces. I’d like the record to survive a move into a spaces when that launches.

Proposed lexicon

({ns} is a placeholder until there is a name)

Core (belonging to this app’s domain)

  • {ns}.note: the note itself. Might include Title, description, video blob (MP4), thumbnail blob, aspect ratio, duration, capture kind (display, window, region), “listed” flag, timestamps. I like the idea of this maybe being spaced alongside other types of community lexicons for notes (text, voice, image…)
  • {ns}.note.defs: any shared definitions such as capture kind and visibility.
  • {ns}.comment: a comment on a note, with an optional time anchor in milliseconds and an optional parent for replies. I see bsky posts possibly used here in conjunction but not sure of the implications.
  • {ns}.transcript: captions and transcripts, language plus a WebVTT blob, human or automatic.
  • {ns}.collection: an ordered set of notes (e.g. for a series, project or course)

Borrrorws - existing lexicons I’d reuse / connect to interactions:

  • Streamplace streams and VODs as source material (similar to how you can create clips from youtube VODs and streams…)
  • Bluesky posts as comments

Scope

My MVP scope looks something like this right now: {ns}.note as one record, carrying its own metadata, plus profile reuse and the listed flag. A desktop recorder (Electon), MP4 up to 10 minutes at 720p, uploaded straight to the user’s PDS, within its blob limit.

Designed for but not built: visibility levels and Spaces, comments, transcripts, collections…

Out of scope for now: Import Streamplace clips, Post to Bluesky, Bluesky posts as comments.

What I’d like input on

  1. One record or more?
  2. A neutral community namespace, or an app-level namespace?
  3. A listed flag now and a visibility enum later: will that survive a move into Spaces?
  4. Is anyone else already modelling something like this, so we can share / collab?

—

Also, different but related topic. I don’t have a name for this yet and I’m not inspired.

Suggestions welcome across the board!

Thanks y’all.

1 Like
2

Great write up. I’d start with planning for spaces day 1, but you don’t really need to design anything into the lexicon for this I don’t think. That’s an app view / app concern.

Public vs Unlisted still makes sense too, these are pretty standard patterns.

I actually don’t think you need a limit? This is another meta item where blob size limits and other parts of the system are going to affect this.

I probably wouldn’t put collections directly in this lexicon. We don’t have generic collections and it’s a good point: what IS a list of lexicon objects? (That’s not a feed). I guess Semble collections and Grain albums are counter examples.

Tags are also likely to be useful.

Comments using rich text and just holding a Bsky post embed could be a thing. And, an app can look for back links without being a comment per se. I think having a first class comment for timeline remarks is good. I’d look at what Leaflet is doing.

I’m actually a bit confused by just seeing “note” - but I guess you’re leaning on the NS for that. I searched a couple of .video domains and there a bunch that might be relevant.

I get what you’re thinking about “maybe it’s all notes but they are typed” … but at that point I just want a collection that can hold many different lexicons.

For Streamplace VODs, I believe it goes beyond blobs to point at external S3 compatible storage - I don’t know how to model this, a blob OR an external link? @iame.li will tell us.

Other than being adamant that these are “simple” video notes and not important video notes — is there anything here that doesn’t make sense for videos generally? Or is your Loom use case just a way to build an opinionated app that focuses on that style of video?

3

Hi – I’m working on a transcript format for atproto with Streamplace and Ionosphere, provisionally called TAML (Transcript And Media Layer). You’ve put {ns}.transcript aside for now, so it might be worth a look. Transcripts apply to any video, so one shared lexicon would save each app making its own.

The text and word timings go in chunk records. A transcript record holds the language and speakers, says how the transcript was made, human or automatic, and points at the video record. WebVTT is generated from the records when a player needs it. For a 10-minute note that’s one transcript record and one chunk. Word timings let you show an interactive transcript or karaoke captions perhaps :slight_smile: .

Corrections and translations are there if you want them later – a correction is a new version, and a translation points back at the version it came from – but you don’t need them to start.

On Boris’s point about blobs and external storage – the transcript points at the video record, so it doesn’t matter where the video bytes live.

On comments with a time anchor – if we both count milliseconds from the start of the media, a comment could also point at a range of the transcript text.

Spec: Transcripts on atproto and MUXL – draft recommendation · GitHub
Guide: TAML – A Developer's Guide · GitHub

The record names are placeholders for now. Happy to talk it through.

1 Like