kb1rd / matrix-notepad Goto Github PK

Matrix Notepad is cool, but fairly useless in isolation. IMHO, there should be a way for people to make applications on top of Matrix without having to re-invent the login screen, among other duplicated things, every time. Plus, as a user, I don't want to sign in to a ton of different Matrix-based applications, nor do I want all the signed in devices, nor do I want every cool looking application to have complete access to my account. The solution is to have an app hosting protocol that allows client applications to be loaded in iframes with managed access to a user's Matrix account.

I am working on a Matrix Apps host application like this. When I am done, Matrix Notepad should be moved over to Matrix Apps and mostly re-written since the codebase is a complete mess.

When Ctrl + Z is pressed, behavior must be well-defined. In the current case, text from the initial sync is removed with undo, which may come in with a different order, so very old changes are most likely the first to be undone. For the average user, this makes no sense. Since timestamps cannot be trusted, establishing order of undo operations would be difficult. I'm considering the following approaches:

• Establishing order in the DAG based on event depth (complicated)
  • Also leaves the ambiguous case of multiple events with the same depth. What then?
• Only allow undoing of changes that happen while the user has the editor open
• Only allow undoing of local changes made by the current user (may make more sense for UI/UX)

Using an element hosted server, I see 429 errors:

Object { errcode: "M_LIMIT_EXCEEDED", name: "M_LIMIT_EXCEEDED", message: "Too Many Requests", data: {…}, httpStatus: 429, stack: "" }

The app should be nice to home servers :-)

This should be really easy to implement since the Matrix JS SDK exposes pretty much all the APIs necessary for chat. Comments would need a custom event type with a position(s) in Logoot.

Until I do some actual debugging, it's hard to say if this is one or multiple issues, but I have encountered removed text that I can't seem to get rid of. It happens when text from a large (multi-character) insertion is removed.

Possible things it could do:

1. Enable breakpoints at each incoming message
2. Allow the user to view and search the sorting trees
3. Allow the user to view Logoot positions

All said and done, its around 24MB that gets sent to the client. This is insane. I really need to figure out where all this is coming from and eliminate it. I have a feeling that most of it comes from the UI framework that I'm using. I should import only the components that I need. First, I want to get this to a stable state though.

This is absolutely possible to implement right now but I'm holding it back until squashing (issue #11 ) is finished so that I don't have to re-write or re-consider anything. The main consideration with this is UI/UX and metadata leakage. First, there needs to be a clear way of letting the user know that some events cannot be read until E2EE keys are exchanged. Finally, metadata about when, how quickly, and whether a user is inserting or removing text would be leaked. The latter could be solved by making all event types the same and adding a field in the event for the type. By far the largest metadata leak would be through squashes. Because the server would need to filter events into the appropriate threads, some knowledge of the overall structure of the document could be gained by seeing which squashes contain a particular event.

ATM, filtering is done on the client side, meaning the client receives ALL messages when it tries to sync back. Filtering is provided in the Matrix JS SDK and should be used. This will require resolving matrix-org/synapse#4299

Rich text refers to having inline embedded content (such as mentions), block embedded content (such as images), and marks in the text (such as bold or italic). This could actually happen really soon. Like in a few days if I really wanted to go quickly. Why?

TL;DR: Since the algorithm is data-agnostic, I can push anything through. I did a bit of future-proofing in the event representation, so all I really need to do is stop being lazy.

Here's an example event:

{
  "type": "net.kb1rd.anchorlogoot0.ins",
  "sender": "@kb1rd:kb1rd.net",
  "content": {
    "a": {
      "v": 0,
      "o": []
    },
    "d": [
      "Hello"
    ],
    "c": 0
  }
}

(For reference, the a contains the anchors, which are undefined in this case, so it anchors to DocStart and DocEnd. d corresponds to the data. c corresponds to the Lamport clock)

If you look closely, you'll notice something odd: The data is actually an array of strings. Why? Well, because you can't embed an object in a string. This is future-proofing to allow individual characters to be efficiently mixed with objects. If one wishes to embed one or more objects in the string, they could add an array of objects to the current data array. On the receiving end, each element in the data array would be merged end-to-end. It's easier to see an example:

{
  "type": "net.kb1rd.anchorlogoot0.ins",
  "sender": "@kb1rd:kb1rd.net",
  "content": {
    "a": {
      "v": 0,
      "o": []
    },
    "d": [
      "Hi ",
      [ { "type": "net.kb1rd.image-block", "url": "mxc://myimage" } ]
    ],
    "c": 0
  }
}

I could just as easily make that an array of characters, but the JSON representation would be less efficient. You may be wondering why I need the array brackets around the object. The reason for this is because it lets the clients know that each element of that array is an atom and cannot be broken. It is still algorithmically correct to distinguish between a string that is a single atom and a string that is a set of atoms. So, if you wanted to send a single-atom string (though most clients would likely discard it), you could set "d": ["each letter is an atom", ["this is an atom"] ].

The current method for scrolling back consists of receiving an event backlog (50 events or so) and checking to see if it has any relevant messages in it. If it does, another sync request is sent to look for additional events. I've encountered issues where there appears to be a blank document, but quite a lot was returned in the sync request, indicating that the document events might have been drowned out. This is more or less the same issue as #6, but I thought I'd mention it in case anybody opens a blank document. I had a feeling this would be a problem on busier servers, but I was more focused on fixing the core algo. sigh

It's really awkward to edit when you can't see where other users are editing. The simple solution to this is to send an ephemeral event that holds the user's typing status, but custom ephemeral events are not yet supported. This is blocked by MSC2477 (matrix-org/matrix-spec-proposals#2477).

Currently, all rooms are displayed in the room list. This is a bad idea since the user can easily pick a room that has a long chat history and is not a document. There is talk of creating a room tag or similar for filtering by room type in the issue https://github.com/matrix-org/matrix-doc/issues/423.

The current method of figuring out what the contents of the document are is to sync back to the start of the document. This means that the time to sync gradually increases and increases until the program becomes unusable. The only solution that I can think of this is to create "squash" messages that copy old messages into a single "squashed" message containing the text in a certain region.
However, this creates a large problem. Let's say that early in the edit history somebody adds a paragraph or so that nobody changes later. Most likely, a smart algorithm would "squash" this paragraph relatively early on. This would require each client to still sync back that far to fetch any additions that could've been made to that squash since it was created. The solution, in my view, is to group messages associated with a certain squash together in a message thread. This is a WIP proposal for Matrix under issue https://github.com/matrix-org/matrix-doc/issues/1198. The requirements for threads to be used for squashing:

• Be able to send full Matrix messages to each
• Be able to sync/filter threads separately from the main room
• Be able to create threads inside threads infinitely

Let's say both Alice and Bob both insert a character at the same position at the same time. These new characters will both have the same ID and the same vector clock. That means whichever arrives first is visible. These conflicts should be at least shown somewhere and preferably should allow the user to resolve them.

Pijul is a patch based version control system with better conflict resolution than Git.
There is a social coding platform for Pijul: https://nest.pijul.org/
At the moment there is no code review feature in the Pijul Nest.
Is there any way it could be implemented in Matrix Notepad?
This would require #14 to be completed.
Maybe some server side code would be required (to fetch the patches from the Pijul Nest).
The original content of the patch can't be modified, so every edit should be rendered as a suggestion.
Would this be useful in Matrix Notepad, or it would be feature creep?

Original text:

Collaborative Text Editing

This document described

Hello

Result for the other user:

Collaborative TtinThis docuentm describedHello

Use https://github.com/matrix-org/matrix-widget-api to allow the Notepad to function entirely as a widget. This would be instead of using mxapps, which I don't think makes sense since the widget API is gaining most of the features that mxapps would have.

This depends upon matrix-org/matrix-spec-proposals#2876.

Getting the access token is awkward and annoying. It also encourages people to re-use devices.

Your Matrix room is inaccessible.