Onion service data model is a hack
Onion services can use sub-domains and are long-lived, which means that they have some advantages over the mirrors system, but this also means that they need to be handled differently. Simply integrating onion services as another kind of mirror provider isn't going to give the desired effects, or is going to be a UX disaster with a lot of copy/paste on the part of the user.
Rather we can add a new model:
Origin domains |
---|
id |
domain_name |
onion_hostname |
We'd then change origins to contain the subdomain part, and link to the origin domain with a foreign key.
Question: is there any benefit for the mirror system if we group by top-level domain?
Question: would a future oniongroove setup use subdomains in the same way that EOTK does? (@rhatto)
Question: is it worth implementing? we're pretty close to having self-service onion service deployment via this dashboard, we'd only need to add uploading onion keys and tls certificates and storing them into an S3 bucket to finish the job. saying this, if we're done deploying onion services and the only reason to have this in here is to add the onion services to the JSON output, maybe we just have the consumers read a different JSON file to get the onion services?