Feature Proposal: "Pages" tab for long-form content

[ahmadmucom]

Feature Proposal: "Pages" tab for long-form content

Been using Memos for a while and honestly it's become my go-to for quick notes. Replaced Telegram Saved Messages with it and never looked back.

The one thing that keeps pushing me to other tools is longer content. I write technical guides (undervolting, mobile optimization, etc.) and keep a travel diary, and these just don't work well as memos. They need titles, structure, a proper reading view.

I looked at running a second app alongside Memos but I really don't want to. Memos already does 90% of what I need.

The idea

Add a Pages tab in the sidebar next to Memos. Simple as that.

• Memos stays exactly as it is, nothing changes
• Pages is just a separate space for longer markdown content with titles
• Tags work across both so everything stays connected
• Same storage, same philosophy, just one extra tab

Here's a quick mockup of what I have in mind:

The core concept: quick thoughts go in Memos, longer stuff goes in Pages. One app, one container.

Happy to build this

I'd like to implement this myself. Just wanted to check if this is something that fits the project's direction before I start writing code. Open to any feedback on the approach.

Cheers!

[ahmadmucom]

@boojack

[ahmadmucom]

@memoclaw

[ahmadmucom]

I'm willing to implement the feature, maybe memoclaw can implement it if you prefer that. I'm asking asking if the PR will be merged or ignored. Asking to contribute not just asking for a new feature @boojack

[bluedbird]

Thanks for the detailed proposal and the mockup — clearly a lot of thought went into this!

Right now our focus is on perfecting the instant capture experience — there's still a lot to do on that front. That said, we have been thinking about article/page-style content for the future, similar to how X has posts and articles.

If you're serious about pushing this forward, we'd love to see a more detailed design doc covering store schema changes, proto/API changes, and how it integrates with existing features (tags, search, visibility). That would help us evaluate the full scope and plan it properly.

[ahmadmucom]

Thanks for the feedback! Here's what I'm thinking:

Store Schema

New page table separate from memo, same conventions (SERIAL PK, UID, JSONB payload, Unix timestamps):

Column	Type	Notes
id	SERIAL PK
uid	TEXT UNIQUE
slug	TEXT	Auto-derived from title, editable. UNIQUE per creator
creator_id	INTEGER FK → user
title	TEXT	Required the key difference from memos
content	TEXT	No length limit
visibility	TEXT	PRIVATE / PROTECTED / PUBLIC same model
pinned	BOOLEAN
payload	JSONB	Tags, property (word_count, has_link, has_code, etc.)
row_status	TEXT	NORMAL / ARCHIVED
created_ts / updated_ts	BIGINT	Unix epoch

Why a separate table? Memo queries stay untouched (no WHERE type = on every query), different field requirements (title+slug vs parent for comments), and they can evolve independently. Consistent with how each resource already has its own table.

Comments on Pages: Reuse Memos as comments via a new page_relation junction table (memo_id, page_id, type). Same pattern as memo_relation for memo-comments. Comment-memos get filtered from the main timeline the same way memo-comments already are.

Attachments: Add nullable page_id to existing attachment table. Same upload/paste pipeline, just a different FK.

Reactions: Existing reaction table, content_id = pages/{uid}.

Migration for all 3 drivers (postgres/sqlite/mysql) at version 0.28.

Proto/API

New PageService in proto/api/v1/page_service.proto:

• CRUD: CreatePage, ListPages, GetPage, UpdatePage, DeletePage
• Attachments: SetPageAttachments, ListPageAttachments
• Comments: CreatePageComment (creates a Memo + page_relation), ListPageComments
• Reactions: ListPageReactions, UpsertPageReaction, DeletePageReaction

Follows the same AIP patterns as MemoService page_size/page_token pagination, CEL filter expressions, field masks for updates.

Page message fields: name (pages/{uid}), title, slug, content, visibility, tags (OUTPUT_ONLY, extracted from content), pinned, attachments, reactions, property (word_count, has_link, etc.), snippet.

ACL: GetPage, ListPages, ListPageComments are public (visibility enforced at service layer). Everything else requires auth.

SSE events: page.created, page.updated, page.deleted, page.comment.created.

Registration in v1.go follows the existing pattern embed UnimplementedPageServiceServer, register gateway + Connect handlers.

Integration with Existing Features

Tags: Identical system #tag syntax parsed by the same markdown parser, stored in payload.tags JSONB. Tag sidebar shows aggregated tags from both memos and pages. Clicking a tag filters within the current view context.

Search: Same CEL filter mechanism. Pages get an additional title filter field. SearchBar targets the active resource (MemoService on /, PageService on /pages).

Visibility: Same PRIVATE/PROTECTED/PUBLIC model, same access control checks, DisallowPublicVisibility instance setting applies.

Image paste (Ctrl+V): Reuses MemoEditor's existing clipboard → AttachmentService.CreateAttachment → inline ![](url) flow. Zero new upload code.

Cross-linking: New markdown syntax [[page:slug]] and [[memo:uid]] for linking between resources. Parser addition in plugin/markdown/parser/, rendered as links.

Explore: Combined feed at /explore with a toggle (All / Memos / Pages).

RSS: Public pages included in feed with title + snippet.

Slugs: Unique per creator. URL structure: /pages/{username}/{slug} for public pages.

Frontend

• New routes: /pages (list), /pages/:slug (detail)
• "Pages" nav item between Home and Explore
• Page editor: title field + reused markdown editor with full toolbar and image paste
• Page cards in list view: title, snippet, tags, word count, date
• Comments section on page detail view using existing memo editor

Phasing

1. Backend: Proto + store + migrations + API + tests
2. Frontend: Routes, navigation, list/detail views, editor
3. Comments + cross-linking
4. Polish: RSS, MCP tools, explore integration

Let me know what do you think, happy to start on this

@memoclaw @boojack

[ahmadmucom]

@boojack not sure if we're aligned ? before I start the implementation ?

[boojack]

#5714 related to this discussion

[nathancartlidge]

Just to provide an alternative perspective - I think this feature would be great, but unsure if adding a second back-end schema is the best approach. It might be better to have pages also be implemented as memos, but split them in the UI?

Changes still needed with this approach:

• Alternate editor (e.g. split out title for input purposes, but it can be embedded in the actual post as just a markdown h1)
• Alternate renderer (better long-form viewer, maybe closer to GitHub's markdown renderer in basic style terms (mainly: full-width)
• If we want to implement cross-linking, this could also be a UI feature (i.e. write the 'pretty' link, but it resolves to the full memos url)

I think this "split-frontend" could be simpler to accomplish and maintain than a "split-backend + split-frontend" approach.

Caveats:

• If we want to separate pages vs memos with a tag, we would need to 'reserve' it - this could easily cause problems
• Some potential edit model issues - would it be possible to 'corrupt' the memo in such a way the renderer/editor don't recognise it?
• Would not allow for custom URL slugs without further work - unsure how important this is to you.
• RSS feed would be more complex compared to a separate db, but could be a separate feature - maybe creating RSS feeds for a tag, which could be reused for this?
• Potentially some search issues at scale compared to having a database-indexable title

Just my view, happy to discuss further!

[ahmadmucom]

@nathancartlidge Agreed, frontend-only split is cleaner.

I'm done here though. Wrote a full UI mockup and detailed design doc covering schema, API, and integration with every existing feature. The response was linking a "show more" button issue as a duplicate. I guess that's what passes for feature evaluation around here.

Feel free to use any of the ideas.

[bluedbird]

Interesting discussion! I think @nathancartlidge's instinct about a frontend-only split is on the right track — a separate page table introduces significant complexity (new proto service, 3 DB driver migrations, new API routes, duplicated tag/search/visibility logic) for something that can be achieved more simply.

My take: the only real difference between a "memo" and an "article" is whether the content starts with an H1 heading. So rather than a new schema, we can extract a title field into the existing MemoPayload.Property during markdown parsing. The frontend then checks property.title != "" to decide how to render — article view with a prominent title, full-width layout, etc.

What this gives us:

• Zero migration, zero new tables, zero new API endpoints
• Tags, search, reactions, relations, attachments, visibility — all work unchanged
• A memo becomes an article simply by starting with # My Title
• The existing RebuildMemoPayload runner backfills titles for all existing memos automatically
• Can always be "graduated" to a separate table later if articles become a first-class concept

Trade-offs to be aware of:

• No custom URL slugs (articles use memo UID like any memo)
• No separate API-level filtering (though a CEL filter on title could be added)
• Title is a convention (first H1), not a dedicated input field

I've put together a backend implementation in #5726 — adds string title = 5 to Property in both store and API protos, with extraction logic in the markdown parser. Frontend work would be the next step.

[Novapixel1010]

This sounds like the best option