Get rid of origin if possible - less config, easier data migration, moving server between domains

[joepio]

Atomic Data uses a lot of URLs. The server needs to be aware where it is hosted in order to provide valid JSON-AD.

However, this poses a problem: Changes to port or schema (using HTTPS or HTTP) or domain causes identities to no longer resolve.

This requires users to migrate their data manually (e.g. export JSON-AD, rename all domains).

It would probably better to use a different type of ID internally. For example, instead of storing local identifiers as https://domain/ we do something likelocal:.

• Whenever we serialise any resource, we need to convert it using the server_url.
• We need to consider all the places where we use these URLs:
  • Properties
  • Values

[AlexMikhalev]

I like the idea of introducing atomic:// URL scheme and use current tauri app to register atomic:// schema locally, with an atomic server internally translating URLs to relevant FQDN + path. To illustrate our discussion check out how ripgrep handles URLs schemas for different text editors: Printer