What you're describing is very similar to Rubber duck debugging. The idea here is that forcing you to explain what you're trying to do makes it easier for you to catch your mistakes.

https://en.wikipedia.org/wiki/Rubber_duck_debugging

Nobody is demanding you do. But if you go around claimng people "got phished", then you should be sure.

I've also entered fake credentials into a clearly faked login form to see what'd happen. Would it redirect me to the right site? Just claim the information was wrong? Send me to a mock up of the intranet I was trying to access? You can call it bad policy if you want (although you don't know about my precautions), but it doesn't mean I was phished.

What it does mean, though, is the person who sent the email now knows, at the minimum:

1. Someone receives and reads the email sent to this email address.

2. That person is willing to enter data into a form.

This is 2 pieces of information the person didn’t have before, and it can be used in further phishing attempts in a variety of ways.

It doesn’t mean you were fooled, but that’s only half the story.

With fear of starting a fire here, are you using an Android phone?

I'm asking, because whenever I hear people complain about phone software that just breaks, it's almost always Android, and with good reason: They have to support a lot more phones than iOS, and Android is a lot more open.

So I just wanted to air the idea that you could try with an iPhone. iOS may lack some of the feature Android users are used to, but in my experience, it's just more stable, and I don't at all share the sentiment that "phones are unusable" or that the audio quality is bad or anything of the kind. If there's one device I can always count on working, it's my phone.

In android, radio stack is chipset specific and the OS interacts with it via RIL, provided by chipset vendor. It has nothing to do with "has to support a lot more phones than iOS"; in both systems the OS does not touch the audio streams, just routes them from/to input/output.

I think you jumbled up the two paragraphs. Nowhere did I suggest that poor audio quality was because Android has to support more hardware.

That's an interesting project and good writeup!

Peer-to-peer OT has indeed been proven wrong many times (I've debunked a few papers myself as well), but client-server-based OT is very solid.

For the last 3 years, I've been the primary developer on Webstrates[1], an open source[2] research project that "makes the DOM collaborative", that is to say, as Google Docs (and your project) makes text editing collaborative (a subset of the DOM), Webstrate aims to make the entire DOM collaborative, allowing developers to easily built collaborative tools (such as text editors).

In fact, I just made a basic editor here (https://demo.webstrates.net/dom-editor/) in about 5 seconds. I just created a new webstrate (a "page" on the server) and added the `contenteditable` attribute to the body element. Of course, it dosen't have any of the rich text editing capabilities of your editor, but that's just a matter of adding more stuff directly in the DOM, e.g. https://demo.webstrates.net/shaggy-elephant-60/?copy.

Through those 3 years, there haven't been any DOM consistency errors caused by issues with the OT algorithm used.

Absolutely nothing wrong with CRDT – it's even on our own agenda to eventually develop a peer-to-peer-basd Webstrates using CRDT. I just wanted to point out that OT is a very viable alternative for client-server applications.

[1] https://webstrates.net/, [2] https://github.com/Webstrates/Webstrates

You may find ShareDB[1] interesting – it's a library that does exactly that.

>ShareDB is a realtime database backend based on Operational Transformation (OT) of JSON documents. It is the realtime backend for the DerbyJS web application framework.

And now a selfplug:

We're using ShareDB to create collaborative DOM in Webstrates[2]. The tl;dr is that every DOM change you make gets synchronized to all other connected clients and the document (including full version history of every single DOM change) gets saved.

Creating a collaborative editor in Webstrates is a simple as creating a new webstrate[3], opening Devtools and adding `contenteditable` to the body element.

[1] https://github.com/share/sharedb, [2] https://github.com/Webstrates/Webstrates, [3] https://demo.webstrates.net/frontpage/

Any fake-Facebook website can copy Facebook's favicon, so that wouldn't add any security at all.

An identicon is a hash value represented as an icon. "facebook.com", for instance, may hash to a red image with a yellow line through it. While you wouldn't remember the icon initially, over time you would – or at least your subconsious would. If you ever visisted a fake-Facebook, you'd immediately notice that something was wrong if the icon suddenly was green with a blue dot in it, for instance.

There is a change history. No changes are lost.

This isn't for a banking system, this is for building collaborative apps. If you press "A" and your friend press "B" into a Google Docs document at the same time, you also don't know if the document is going to read "AB" or "BA". In practice, this is not an issue.

My experience is with OT, so I can't speak for CRDT, but I can imagine it's similar.

With OT, you send a na[1] (number add) operation, so this would work fine. Indeed, if you treat the number as a string, then you have a problem.

[1]: https://github.com/ottypes/json0#summary-of-operations

This doesn't compose with all operations. One users adds and another user multiplies, for example. That is to say, not all operations are associative.

I bet you can run really far with this general idea. But there is no panacea.

You're absolutely right, but I'd also never suggest a collaborative system for anything critical. As I've said earlier in this thread: If you're in a Google Docs document with a buddy and you write "A" and he writes "B" at the same time, you also don't know whether that'll show up as "AB" or "BA". In practice, this isn't an issue.

To underscore our point, concatenation on strings is not associative, either.

To that end, the basics of math in associative, cumulative, distributive, etc., go together to create an algebra of what you can automate rather easily. I think most of us stopped thinking in terms of those laws years ago. To the point that it is probably odd to folks that stayed close to them.

> To underscore our point, concatenation on strings is not associative, either.

I think you mean commutative. It certainly is associative.

Ha! Yes. I meant to draw attention to all of the fundamental laws people are used to. Messed up in some edit.

Thanks!

Then there'd be a negative amount of apples. It's not impossible if you disregard context.

There is nothing new about doing things like this, OT and CRDT have existed for ages. Check out ShareDB (https://github.com/share/sharedb) or Webstrates (https://webstrates.net/) (based on ShareDB). In Webstrates, we don't have merge conflicts that need to be resolved and there are never any practical synchronization issues. The server orders the operation and if you try to delete something that's already been deleted, then we just ignore your operation.

Also quite courageous to say something is impossible when you have the code that does it right in front of you. ;-)

I think when we say "impossible" we mean "well sure any old thing is possible but there are hard limits on what's consistent and sane."

I will go read the docs in more detail but what you've just describes sounds pretty awful. Perhaps it's more just you being glib about non-cooperative actors in an environment that expects cooperatuon, but an "available balance" abstractions are a pretty reasonable thing to ask for, if only to encode natural numbers.

I'm not one to dictate how technologies like these are to be used, but all I can say is that in the almost two years I've been working on Webstrates – a collaborative system using a very similar technology – this has not been an issue.

But surely, if you allow malicious actors to modify your document, then that's your problem right there.

It's still impossible in the general case. You merely proved him right. Limiting yourself to OTs and CRDTs is a signficant restriction.

Why is that a restriction? You can make any changes to the JSON you wish, you just have to use their API.

ShareDB looks quite interesting. We wanted similar capabilities but without a central authority, thus automerge was born.

We've been wanting to try a CRDT-based implementation with Webstrates for some time, but haven't found a suitable implementation, so this looks very promising!

Any particular reason why you choose CRDT over OT?

I'm told OT gets very complicated, and I hoped a good CRDT would be general-purpose enough to cover a variety of applications and domains. Also, I like not needing a central server to coordinate action. Would love to compare notes -- feel free to reach out to me on twitter at the same nick.