the technical docs are over my head. from what i can see theres no subnames under uni.eth so these seem to be a completely different kind of mechanism than the subs iām familiar with
can these uni subs also host records, to change resolution address or add other chain addresses? are they unruggable like a wrapped + burned fuses sub is?
thanks
Similar to *.cb.id subnames, they are so-called āoffchainā names. They are not registered on the actual Ethereum blockchain. Instead, an ENS resolver allows clients to fetch data from some web2 centralized server. That is whatās happening here. The subnames and all records in this case, are stored in a companyās private database usually. They are not unruggable, as they are not NFTs, and not onchain at all.
Such subnames can still support all record types, but itās up to the company hosting them to provide access to update those records. For example if you claim a cb.id name in Coinbase Wallet, then I believe you can change a few things in your profile that will reflect in the ENS name records.
So this only works if the service, platform or provider supports their off-chain resolver?
Maybe I should dig into EIP-3668 & ENSIP-10 a little more. The way I am and have comprehended the way this works; while as If I remember correctly, I do not remember signing a message when āregisteringā (or assigning in this particular mechanism) my subname.uni.eth. With being off chain in an unknown database, essentially these addresses are not secure and could easily be changed to route funds to a different address in the event of a security breach of this said daabase?
In more realistic terms: Uniswap is using the EIP-3668 CCIP READ & ENSIP-10 WILDCARD RESOLUTION to skip registration fees, and use this for no benefit of the DAO. So if platforms or provider are not required to support this; where is the data being communicated to the off-chain provider?
i.e; the (URI?) exists somewhere in the their front-end which points to the off-chain resource. If that were to be compromised then the off-chain resolver becomes at risk of redirecting to a malicious provider that would in theory return one address for all subnames?
Well in this case the library becomes the resolver in lieu of an on-chain immutable mechanism, right?
No, the service/platform/provider does not have to support any specific resolver. It only needs to be using a client library that supports CCIP Read and ENSIP-10 (and all the major ones do to my knowledge, like ethers, viem, ensjs, web3.py, etc).
So a frontend developer does not need to do anything special, everything will work seamlessly out-of-the-box with any of those common libraries.
The return data cannot be spoofed by a mitm, as it gets verified onchain in a subsequent call, that is part of the CCIP Read spec.
Who is the authority of assigning a sub-name with a wallet address?
Does this have anything to do with why Uniswap chose to only support creating the subnames via mobile device, which is more difficult for people to look at source code rather than the desktop browser experience?
Ok so the libraries you mentioned support CCIP but where is the infrastructure ? Where does the library differentiate what resource to read from?
If you own a name, you can create any subname you want and point it to wherever you want. That goes for .eth names as well as imported DNS names, whether they are onchain or offchain.
I think the author wanted it ābrieflyā 
I just registered a *.uni.eth and the process is very easy. 