Make it clear that shared pad is synchronizing something

[parkan]

One remaining UX wart with the slimmed-down peerpad is that an unsynced pad looks the same as a blank one. The UI also isn't locked if you're online but not fully synced, so you can potentially start performing inputs leading to undefined behavior (sometimes it seems to override the entire state, sometimes it gets incorporated into history)

I am wary of locking the UI entirely, but a prominent initial sync indicator seems necessary.

A comprehensive solution would probably incorporate an indicator system conveying both peer sync and pinning status, but for basic dogfooding usage we can use something more ad-hoc.

[jimpick]

It really shouldn't ever override the entire state ... what I saw today was that you edited a document that Dirk and I had collaborated on, but I think the pinner had somehow lost the data from the original editing session (rebooted maybe?), so only had your edits when I rejoined.

When I re-connected the browser that was in the original editing session, the data from both sessions were merged.

[pgte]

@jimpick about this last problem you described: Currently the pinner doesn't keep multiple heads, it simply resorts to storing one. One thing it does is it never "goes back" in time, but if two distinct replicas diverge and they're not connecting to each other, the pinner is not able to merge these changes (because the pinner doesn't know the content of the state).

Here is an issue to track this particular problem: https://github.com/ipfs-shipyard/peer-star-app/issues/201

@jimpick do you want to take attempt to solve this?

[pgte]

@parkan I believe that a bootstrap process state machine was being discovered by @marcooliveira and @andreforsousa (in the context of Discussify, but I believe it can be applied). Perhaps we could reuse that?

[marcooliveira]

Yes, this is something we're currently working on. Will come back once we have an update, we should have a draft this week.

[parkan]

a state machine similar to the new go-ipfs connection manager FSM is likely the real fix (I'll make a new issue), but maybe a simpler hack can address this particular issue

for example, we can set a url fragment (...#edited) and when pasting the URL into a new window we can know that this isn't a fully blank pad and show a general synchronizing state, instead of the new pad

even more simply, we can show the "welcome to peerpad" text only when loading dev.peerpad.net w/o anything else in the URL, and show a "synchronizing..." text in the same way otherwise

[jimpick]

I'll see if I can cook up a test case...

[marcooliveira]

For reference, this relates to: https://github.com/peer-base/peer-base/issues/227

[parkan]

thoughts from @momack2:

When you are sent and click on a peer-pad link that points to an active doc that is being shared with you - the redirect/loading page should look different than a blank peer pad. The UX problem is that you are following a link that someone sent you to notes and on first load it looks like a blank/empty peer-pad - which gives the impression that all the previously added data has been lost, or you were sent a wrong link (without a reference to the specific doc).

Instead, when editing a peerpad, the link in the URL bar / in the "share" button should have some sort of special marker that differentiates it from a brand fresh peerpad doc. On click of that link, there should be a "loading" screen while IPFS tries to find the document content in the DHT - only after timeout should the user be prompted to create a blank peer pad (and I assume it will have a different weblink, no?)