[yellowapple]

Plaintext doesn't take up all that much space relatively-speaking; it'd be entirely feasible to store all the data on an automotive title (for example) directly on-chain.

Also, there's no reason why the property and conditions have to be stored together; they could readily exist as separate artifacts sharing some ID or reference.

[Yizahi]

First - that's a big if. Only super bare and short, zero formatting plaintext, will fit inside NFT (as they exist today). I highly doubt people would want to work with such data, degrading their UX dramatically.

Second - do you realise that title contains private information which will be forever exposed on-chain?

Third - ok, even you admit that not everything will fit on-chain. Then who will store the rest of the data? Centralised entity? Which will have its internal security, bookkeeping, staff and so on?

Why do we need NFTs then, if all the work will be done by a centralised entity anyway?

Fourth - in the hypothetical case when we have titles and NFTs linked to them, there are several interesting questions - what happens when owner of the NFT forgets his private keys? What happen if the owner dies? What happens when the court judges declare that the ownership is incorrect? How are marriages handled, where today multiple people can own the same property?

[yellowapple]

> First - that's a big if

That ain't an "if" at all. The actual identifying information on, say, a vehicle title or land deed takes up maybe a couple hundred bytes at most (if not far less), whereas most NFT-capable blockchains allow transaction metadata on the scale of multiple kilobytes.

> Second - do you realise that title contains private information which will be forever exposed on-chain?

Nearly (if not entirely) all of the actually-private data (namely: the owner's PII) is redundant under a title-as-NFT system, since ownership is asserted by wallet/token custody rather than being baked into the document.

Besides, encryption is a thing that exists.

> Third - ok, even you admit that not everything will fit on-chain.

I admit no such thing. What I actually said is that you can break up large data into smaller chunks such that it can fit on-chain even if it somehow blows out the chain's transaction metadata ceiling.

Regardless:

> Then who will store the rest of the data?

Have you heard of IPFS?

> Fourth - in the hypothetical case when we have titles and NFTs linked to them, there are several interesting questions - what happens when owner of the NFT forgets his private keys? What happen if the owner dies? What happens when the court judges declare that the ownership is incorrect? How are marriages handled, where today multiple people can own the same property?

All of these things can be (and, in the case of lost keys, have been) addressed with smart contracts; the blockchain can programmatically define conditions under which the NFT can be transferred, e.g. with consent from multiple parties. Such programs can also represent multi-person ownership; in a world where blockchain computation can handle the governance of large organizations, something like a marriage or an estate is a readily solvable problem.

[Yizahi]

You are using word "smart contract" like it's some magic spell. You can't make a contract with external inputs, from outside the blockchain. Or more precisely, you can't make a reliable "sc" with such inputs. And no, those people claiming to "solve" oracle problem didn't solve anything.

You can't have "smart contracts" applied to the real world without centralised entities controlling them. Therefore they are mostly redundant and unnecessary.

Regarding the size of the title - I admit I don't know much about that area, but I know enough to doubt your claim that majority or even any titles can be reduced under the kilobyte. Splitting info into multiple tokens will only make things even worse.

Also this doesn't address the issue that UX of centralised entity working with such system will be atrocious. You postulate that there will be no centralised entity, but imho that's pure fiction.

And lastly - IPFS will never be adopted for anything important because it doesn't have safety guarantees. Not even with those services promising guarantees for some regular payment. Because subscription can run out, that service may close or anything else can happen, IPFS still can't guarantee file safety. That's a nice toy, but nothing more in the current implementation.