You can check out fabric: https://github.com/spacesprotocol/fabric Let me know if you have any questions

yes it will be in the code around here (this is for testnet4): https://github.com/spacesprotocol/spaced/blob/3107be99977210e45ae62a273decd5a8f9b3094d/protocol/src/constants.rs#L59

yes millions of subspaces can be aggregated into a single hash. Subspace ownership can then be verified off chain with things like fabric

i think so, yes - if they let the onchain subspace utxo expire and are included in the space owner receipt committed onchain afterwards

yes they can take their ownership on chain if they want, and it is treated as a top level space

the zk receipt is published on chain by the space owner so that subspace holders can verify their ownership

the space owner publishes the zk receipt on chain so all subspace key holders have proof of ownership

you can fork the repo and change the launch block number, just as someone can fork bitcoin and create a new chain

no, it has the same rules as a traditional dns name

yes it is client side consensus

subspaces and data related to names can be stored off chain

we have a proof of concept for subspace management here: https://github.com/spacesprotocol/subspacer

you can see how we store data off chain for example with fabric: https://github.com/spacesprotocol/fabric

Most transactions are the size of a regular bitcoin transaction, and limited only to top-level spaces. Subspaces are handled off chain with zero knowledge proofs. So we can scale to billions of subspaces/names with little on chain footprint. The only data stored on chain is the top level space name in the transaction to open the auction. Top level spaces are limited to roughly 10 per day.

sorry I mean we used this syntax to make it less confusing with any conflicts with other naming systems

no sorry but if you have a question let me know

you have to make one tx per year to renew it

built on bitcoin, very little footprint on the blockchain cypherpunk (no premine, no separate token, no foundation) built in a scalable way

it needs to view the relevant transactions in bitcoin blocks to update the state of spaces. It can come online whenever but it won't have updated data until bitcoin syncs and spaced gets the most recent bitcoin block data and transactions

spaces transactions are on chain

whoever holds the key for the subspace is the owner - they prove/verify all updates with their key. We have created fabric for updating data for spaces, and it can probably also be used for subspaces: https://github.com/spacesprotocol/fabric

a sub sub space would probably look like user.bob@bitcoin we wanted to avoid name collisions with traditional DNS which is why we chose this syntax