External Identifiers

[wenzowski]

It's important for identifiers generated on the client to be persisted by the server.

Currently, when we generate a unique uuid on the client and pass that to BacksideServletKS using the lox key we receive a 500 error.

[wenzowski]

The lox string is the correct key for the LOCATOR_PROPERTY.

[wenzowski]

Code path diverges here

[KnowledgeGarden]

Ignoring diverging code paths for the moment. Thinking about the top issue: "It's important for identifiers generated on the client to be persisted by the server."

I cannot imagine what that means. Need to understand what these terms are: client server

To me, TQPortal is the client in question. Sure, it has a server to drive a browser. To me, BackSideServlet is the server in question. I cannot recall where I use the client to generate a UUID (lox). I think there are edge cases where we do, in fact, specify a locator at the client, but those are really rare. For blog posts, etc, as I recall, there's a JSON struct we send from the client to the server, and we leave lox generation to the server.

What am I missing?

[KnowledgeGarden]

The link to code diverging is, in fact, the edge case, where a client is allowed to craft a JSON struct which includes "locator" --> lox. There simply are specific cases where you might want to define a topic at the client and specify its locator. Those are, in fact, extremely dangerous cases, which leads to the need, in that linked code, to validate that a topic with that locator doesn't already exist. In fact, the code does that. An instance of an edge case is found in the typology, where I deliberately gave typology classes semantic names; that's to make it so that you don't have to do a database roundtrip to find the lox for, say, a particular relation or class type.

[wenzowski]

The note on divergence was mostly for my own benefit. 😊 It's throwing errors when used, and as the divergence point that's where to start debugging.

server: BacksideServletKS client: everything else...

A client-generated uuid is only more likely to result in namespace collision if the client has been maliciously compromised. A uuid is probability one unique no matter where it is generated. And if a client has been compromised, isn't clobbering its own objects better than write spamming such that it fills entire db disk? It could do either. To me, the edge case you mention is a distraction from strong RBAC.

Use cases, off the top of my head:

• idempotency. This is huge. Users can and will click submit twice, the network will fail, a handler will not fire, oh-so-many reasons for an op to be submitted twice.
• sockets. And queueing. In a system where we can't guarantee read-your-own-writes or where we need to issue additional writes prior to receiving ack, we need some sort of object identity. Example: create a blog post and add some relations to it. What are we relating back to without a local (client) concept of object identity. I see DDP in here. DDP absolutely needs this.
• replication. At some point this will be a condo in the federation. And even before that, we may wish to import data from an external source, or strongly reference an external source.

[KnowledgeGarden]

I need to look at all code in the TQPortalKS server model to see where it sends a locator.

[KnowledgeGarden]

I think that the theory behind that code was that, if the user specified an instance with a locator, and if that node exists, then return it. I'd like to know how it fails.

[wenzowski]

It fails if the node does not exist. One of the cool features of uuids is that since they're probabilistically unique it doesn't really matter where they're created. So if the user submits a node with an externally (probably browser-generated) lox I'd like to have it committed with that external lox as the canonical identifier instead of throwing. Does that clear things up?

[KnowledgeGarden]

I think that the original design was a kind of shortcut: if you know a unique username, then you just fetch that node by id rather then do a query which could return a list of people who happen to use the same username. However, it's not all that hard in the client to carry around a UUID along with username.

On Tue, May 24, 2016 at 9:18 PM, Alec Wenzowski notifications@github.com wrote:

It fails if the node does not exist. One of the cool features of uuids is that since they're probabilistically unique it doesn't really matter where they're created. So if the user submits a node with an externally (probably browser-generated) lox I'd like to have it committed with that external lox as the canonical identifier instead of throwing. Does that clear things up?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/KnowledgeGarden/BacksideServletKS/issues/9#issuecomment-221469344

[wenzowski]

The rationale behind implementing that shortcut makes sense. This issue is about passing in externally-generated locator UUIDs for any and all existing verbs that currently generate a UUID lox and return that to the client.

[OpenSherlock]

Fog clearing. What is your suggestion?

[wenzowski]

Given design of an RFC 4122 UUID is such that accidental collision is probability zero, allow a lox to be generated external to this codebase and passed in. I'll PR.

[OpenSherlock]

At the same time, we could simply eliminate that edge case entirely. Too dangerous. Not sure I recall all the reasons for it; will have to study TQPortal code, the topic model, to see if we even use it.

[wenzowski]

I had hoped this thread illustrates that there are a) valid use cases and b) no additional danger beyond usual unauthorized access. The system is already checking if the lox exists so it's not an efficiency gain either. The problem is that objects are unadressable until this code has acknowledged their existence. That takes the lovely strong-reference uuids and turns them into weak references just like that.