From: Simon Tatham Date: Fri, 5 Jan 2024 09:13:25 +0000 (+0000) Subject: Add a proper TODO list. X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~ian/git?a=commitdiff_plain;h=29109fb2bca7fe884808dfbfc72a41c9b54ad928;p=mastodonochrome.git Add a proper TODO list. My previous jottings were kept outside source control and not very organised. This is a version I wouldn't be embarrased about showing to an outsider! --- diff --git a/TODO.md b/TODO.md new file mode 100644 index 0000000..748723f --- /dev/null +++ b/TODO.md @@ -0,0 +1,312 @@ +# Missing features + +## Verbose help + +The status lines at the bottom of the screen are all very well, but +real Mono generally supports a `?` keystroke that expands each one +into a full page of explanation. + +## Error handling in the UI + +Real Monochrome has an 'Error Log' at ESC Y V, containing records of +errors that happened in relation to your particular connection, such +as when you tried to read a file but a backend error happened on the +server. We should have one of those, and use it to handle failure to +retrieve things you were trying to read. + +This is already marked in the code with multiple FIXMEs: + +* the `result.expect` at the end of `new_activity_state` +* the handler for the existing `LogicalAction::Error`, which currently + just beeps +* the handler for the return value of `Client::process_stream_update` +* the error in `PostMenu::post`, although if the error is recoverable + (e.g. by editing the text and retrying) then the Error Log is + overkill and we should redisplay the `PostMenu` with the message +* errors in `get_user_to_examine` and `get_post_id_to_read`, although + again if it's just 'no such thing' then the Error Log is overkill. + Should only be for 'help, the server is totally confused'. + +Each of those should instead catch the error, make an Error Log +record, and transfer you to the error-log viewer with a beep, just the +way Mono did it. + +## Tracking what you've read + +When you restart Mastodonochrome and open a feed, it ought to put in +view the first thing you haven't yet read in that feed. This means +tracking what _is_ read during run time, and saving it to a file in +the config directory. + +(Prerequisite: a means of atomically replacing that file with the new +version each time you overwrite it, to prevent data loss. I think +[`tempfile::NamedTempFile::persist`](https://docs.rs/tempfile/latest/tempfile/struct.NamedTempFile.html#method.persist) is probably the tool for that job.) + +Similarly, when the client automatically moves you into the Read +Mentions field because a new mention has arrived, it should +automatically jump the position to the first unread one. + +## Reading + +### Sensitive-content markers + +Currently we ignore whether a post is marked as sensitive: it doesn't +show up at all in the UI. + +We should _at least_ display the sensitive-content tag, because it's +not unheard of for people to use it as a post title, and write the +rest of the toot in the assumption that you saw it, so that it might +not even make sense without. + +Probably better to go all the way, and actually hide the post until +told otherwise. + +### Polls + +If someone posts a toot containing a poll, we should show it, and +offer an option to vote in it. + +An expired poll should show its results. + +## Posting + +### Posting a whole thread + +I want an editor keystroke that introduces a toot boundary marker. +Then you could post a multi-toot thread by editing it all in one go, +with a clear idea of where the boundaries would end up; each one would +be highlighted if it was going to end up too long. + +At posting time, each one would be automatically marked as a reply to +the previous one, and of course the starting toot would still be a +reply to whatever the whole thread was responding to (if anything). + +I think the way to represent this internally is to use a control +character in the editor buffer and handle it specially while drawing. + +### Adding media + +Definitely need some way to add media attachments to a toot. I think +again there should be a control-character representation in the +buffer, and things in the middle of it should be identified as 'not a +character boundary' (using the existing system for that) so that it's +treated as an atomic thing. + +This will need some kind of file selector UI. Not sure whether that +would be better as a straight BottomLineEditor for a filename with +added tab completion, or a full-on full-screen filesystem browser. +Perhaps just the former until anyone has effort for the latter. + +The `Instance` record from the server lists its supported MIME types +for media attachments. I think the +[`magic`](https://docs.rs/magic/latest/magic/) Rust crate will +identify the MIME type of a candidate file, and we could use that to +check whether the file is acceptable. + +The media record in the editor will also need to include a space for +alt text, which you should be able to edit as part of the main editor +buffer. Inserting a media attachment should hint strongly that you +should fill that in, e.g. by putting the cursor in the alt-text slot +and also showing a red error marker for 'no alt text here yet'. + +### Posting polls + +You should be able to post polls, again via some kind of internal +editor markup that inserts magic delimiter characters. + +## Editor improvements + +### Block cut and paste + +There should be _some_ method of cut/copy/pasting a block of text, +beyond the existing ^K cut-to-end-of-line. + +Real Monochrome's UI for this is moderately horrible, and in +particular, works at the granularity of lines rather than characters, +which is not a good fit for this client's auto-wrapping reimagining of +its editor. So I don't know whether to stick with the most Mono-like +thing I can, or redesign more significantly. + +### Importing a file + +Real Mono, for those privileged users with a shell login, has a +keystroke (F8) to read a disk file and insert it into the editor +buffer. That might well be useful here too. + +## Better handling of updates and streaming + +Currently we have exactly one streaming subthread, handling your home +timeline and notifications. But it's also possible to stream other +things: the public timelines (local and global), and hashtags. So +perhaps while you're viewing one of those timelines we should start a +stream thread to keep it up to date? + +This would also require having a way to shut the stream down again. +Public timelines move fast, and you wouldn't want that stream to keep +running forever just because you glanced into the timeline once. +Communicating back to the stream thread to interrupt it in mid-read is +probably too painful, but streaming connections generally deliver a +periodic heartbeat, so perhaps an easier approach is to make a 'please +shut down now' atomic flag of some kind, stick it in an `Arc` so it +can be shared with the main thread, and have the stream thread check +it whenever it happens to wake up anyway. + +Other things can be updated but don't have a streaming API. For +example, if you're viewing a particular user's posts, it would be nice +to append to _that_ feed too if they happen to post something while +you're watching. So another thing we could do is to run a regular +timer tick which wakes us up and makes us poll whatever feed we're +currently watching. + +If we're going to have that poll, it should probably be unconditional, +_even_ if there's also a stream running. Then it acts as a fallback if +the stream gets hung up somehow. + +If a stream connection actually terminates, we ought to at least +notice and log it; perhaps try restarting it after a while; but leave +a decent delay so as not to hammer the server, and in the meantime, +rely on the fallback poll. + +## Menu marker for new things + +In real Monochrome, files that have new things to read are marked in +the menu by a red +. Perhaps at least the home timeline could usefully +be marked that way. + +## URLs in Post Info + +Most Mastodon posts repeat the target of a hyperlink in the visible +text, so you can just copy-paste from your terminal into a browser. +But occasional posts (perhaps federated from other styles of +ActivityPub?) do the more webby thing of having the link text and link +target independent. In that situation you want _some_ way of getting +at the URLs. + +An obvious place to list this would be in the [I] post info page. + +(Actually doing this is probably fiddly, and involves trawling the +`RcDom` structure returned from `html2text`'s first phase.) + +## More logs + +Our logs menus are underpopulated. + +We should have a log of recent HTTP transactions (`Client` is already +in good shape to record one); probably in the form of a list of +one-liners of the form (datestamp, method + URL, status response), and +for each entry, the ability to expand it to look at all the details. + +ESC L should go to a summary page showing general health info; in +particular, whether streaming subthread(s) are currently working. Then +the second L keypress goes to the actual log files. + +## Options key from the Examine User screen + +When you examine a user, pressing O should take you to a page of +options. + +### Client and account configuration: ESC Y O + +If the user is you, then this menu sets client configuration. For +example, the default language for your posts (if you want to override +the one we get from the system locale). Maybe also UI options in +future if we add any. + +It should also let you set server-side options about your account, +such as your display name, flags like `bot`, and info fields. + +### Following/blocking/etc: ESC E [user] O + +If the user you're examining _isn't_ you, then you should get a +different options page which sets your relationship to that user: +following, blocking, muting (or undoing any of those) + +Definitely also the various sub-options of following, such as whether +to include boosts, and which languages to include. + +## Outlying protocol features + +### Scheduled posts + +You can ask the server to schedule a post to go out later. This could +be slotted in as another option in the post-composer menu. + +### Locked accounts + +You can lock your account so that people can only follow you if you +give permission. We should support that: + +* support marking your own account as locked via the ESC Y O options + menu +* if someone then sends you a follow request, make it possible to + receive it and act on it +* support sending follow requests to a locked account + +### Registering an account + +There's an [API +method](https://docs.joinmastodon.org/methods/accounts/#create) to +_create_ an account on Mastodon. Perhaps that means we could support +directly registering via Mastodonochrome, without having to first use +the web interface? + +(Whether or not this is useful in the live Fediverse, it would +certainly streamline setting up a handful of test accounts on a clean +dev instance in a VM, which is a common activity during development!) + +But I'm not sure. The docs for that method say you're required to +provide a user token. But how did you get one without already logging +in as an existing user? I don't quite understand what the flow is for +this. + +### General search + +The [search API +query](https://docs.joinmastodon.org/methods/search/#v2) lets you send +an arbitrary search string to the server, and request accounts and/or +hashtags and/or statuses that match it. Also you can restrict the +search domain to only people you follow, or to only one account +(presumably so you can look up 'that toot I know Chris made last year'). + +### Rate limiting + +HTTP responses from the Mastodon server generally seem to carry a set +of headers along the lines of + + X-Ratelimit-Limit: 300 + X-Ratelimit-Remaining: 300 + X-Ratelimit-Reset: 2024-01-04T19:50:00.318188Z + +If we actually paid attention to those, we could check them in the +centralised `execute_and_log_request` function, and if the 'remaining' +looked dangerously low, set a flag that would make us wait a bit +before submitting the request. Then we should be proof against getting +blocked by the server for accidental misbehaviour. + +### Server information + +The [Instance +record](https://docs.joinmastodon.org/entities/Instance/) from the +server includes information we could usefully show in a page +somewhere. Like the `description` field, and the list of rules. + +There's also an [announcements API +query](https://docs.joinmastodon.org/methods/announcements/) for +announcements from the instance. We should probably pay attention to +that. On client startup, check it for unread ones, and display those +in the style of real Monochrome's MOTD. + +## Archive support + +The Mastodon web UI lets you download an archive of all your own posts +from the user settings menu, in the ActivityPub file format. This +appears to be a zip file containing a handful of JSON files and all +your media (including avatar image and also anything you attached to +your posts). + +It would be nice to be able to use this client to browse that archive, +using the same UI as for reading the live server (restricted as +appropriate where data isn't available). Perhaps even use it _in +conjunction_ with the live server, so that when your posts are in +reply to other posts, you can retrieve the replied-to posts from the +live server if you need to remember what they were about.