Editing posts as a Protocol A improvement (an aux item, proposed upstream) #279

New issue

Open

opened 2026-10-22 11:05:27 +00:00 by littlefox · 1 comment

littlefox commented

2026-10-22 11:05:27 +00:00

Owner

Asked by the user (D-062), 2026-10-22: "File editing as a protocol improvement".

Protocol A can't edit a text. There's no call for it, and nothing marks one text as replacing another (D-061). For 0.7 NeoKOM keeps footnotes as the way to amend a post (#277). This issue is about proposing real editing for the protocol itself, so that every client could show "edited" the same way.

How the protocol grows (Protocol-A.texi, "Defining New Aux-Item Types")

New calls are hard: they need server code and a new protocol version.
New aux-item types are meant to be easy: "document what it does, what the data format looks like and what the server is to do with the item and send this to the LysKOM development group. We'll assign a number". Numbers 20000–29999 are free for experiments.
lyskomd accepts tags it has no definition for, using a default definition (aux_item_default_definition in src/server/aux-items.c). An experimental tag would probably work on today's servers without a server change; to be confirmed on the devserver.

A proposal to work out

An aux item on the new text, e.g. edit-of with data = the text number it replaces. Only the original's author can set it; the server could enforce that in its aux-items.conf rules, and clients would check it either way.
Optionally the reverse, edited-in, on the old text, so a client reading the old one finds the newest version without searching.
What the old text keeps: its number, its replies (they still point at it), its reactions and read marks. A client shows the newest version in its place, with "redigerad" and the history.
Delivery: the new version reaches the same recipients, but should it count as unread for people who already read the original? To decide. A footnote-like link (the new text as a footnote to the old) would let old clients show something sensible today.
Old clients (elisp, jskom) ignore unknown aux items, so they'd see two texts. That decides whether the new version should also be a footnote.

Steps

Write the proposal (data format, permissions, what clients show), and prototype it in NeoKOM behind a setting with an experimental tag, against the devserver only.
Show it to the user. Nothing goes to the LysKOM development group without the user's OK.
If accepted upstream: get the assigned number, then support it for real. Show "redigerad" on edits from any client that writes the item.

No milestone yet; to be placed by the user.

Asked by the user (D-062), 2026-10-22: "File editing as a protocol improvement". Protocol A can't edit a text. There's no call for it, and nothing marks one text as replacing another (D-061). For 0.7 NeoKOM keeps footnotes as the way to amend a post (#277). This issue is about proposing real editing for the protocol itself, so that every client could show "edited" the same way. **How the protocol grows** (Protocol-A.texi, "Defining New Aux-Item Types") - New calls are hard: they need server code and a new protocol version. - New aux-item types are meant to be easy: "document what it does, what the data format looks like and what the server is to do with the item and send this to the LysKOM development group. We'll assign a number". Numbers 20000–29999 are free for experiments. - lyskomd accepts tags it has no definition for, using a default definition (`aux_item_default_definition` in `src/server/aux-items.c`). An experimental tag would probably work on today's servers without a server change; to be confirmed on the devserver. **A proposal to work out** - An aux item on the new text, e.g. `edit-of` with data = the text number it replaces. Only the original's author can set it; the server could enforce that in its aux-items.conf rules, and clients would check it either way. - Optionally the reverse, `edited-in`, on the old text, so a client reading the old one finds the newest version without searching. - What the old text keeps: its number, its replies (they still point at it), its reactions and read marks. A client shows the newest version in its place, with "redigerad" and the history. - Delivery: the new version reaches the same recipients, but should it count as unread for people who already read the original? To decide. A footnote-like link (the new text as a footnote to the old) would let old clients show something sensible today. - Old clients (elisp, jskom) ignore unknown aux items, so they'd see two texts. That decides whether the new version should also be a footnote. **Steps** 1. Write the proposal (data format, permissions, what clients show), and prototype it in NeoKOM behind a setting with an experimental tag, against the devserver only. 2. Show it to the user. Nothing goes to the LysKOM development group without the user's OK. 3. If accepted upstream: get the assigned number, then support it for real. Show "redigerad" on edits from any client that writes the item. No milestone yet; to be placed by the user.

littlefox added the

area/protocol

kind/feature

labels

2026-10-22 11:05:27 +00:00

littlefox referenced this issue from a commit

2026-10-22 11:05:44 +00:00

D-062: propose editing as a Protocol A improvement

littlefox commented

2026-10-22 11:45:35 +00:00

Author

Owner

Parked by the user (2026-10-22): "No action on the issue for the foreseeable future. I just want it archived in an organized manner". Labelled parked and upstream (with #138, the other Protocol A proposal). It stays open so it's easy to find, with no milestone and no work planned until the user says otherwise.

Parked by the user (2026-10-22): "No action on the issue for the foreseeable future. I just want it archived in an organized manner". Labelled `parked` and `upstream` (with #138, the other Protocol A proposal). It stays open so it's easy to find, with no milestone and no work planned until the user says otherwise.

littlefox added the

parked

upstream

labels

2026-10-22 11:45:39 +00:00

littlefox referenced this issue

2026-10-22 11:46:03 +00:00

Roadmap: a Parked section; #279 parked #280

littlefox referenced this issue from a commit

2026-10-22 11:46:04 +00:00

Roadmap: a Parked section; #279 parked (D-062)

littlefox referenced this issue from a commit