Built-in url shorter
https://twitter.com/example On ZeroMe I'm: http://127.0.0.1:43110/Me.ZeroNetwork.bit/?> Profile/1GrEenUGRWnzaNZjR3XsQa6dQgdPDTyt7i/1PPVb3FDDiNyNqbdb5UAv8ykEC1K1Nwquy/[email protected]
If twitter cooperated with third party micro-blogging services, the url will be something like https://twitter.com/[email protected].
Thus I think ZeroMe should be shortened to something like zero://Me.ZeroNetwork.bit/[email protected].
The http://127.0.0.1:43110 can be shortened if a zero// protocol is supported on major browsers in future.
The Profile/1GrEenUGRWnzaNZjR3XsQa6dQgdPDTyt7i/1PPVb3FDDiNyNqbdb5UAv8ykEC1K1Nwquy/[email protected] could be shortened since we already trust zeroid.bit to maintain a list of IDs mapping to key. zeroid.bit could also maps hub address to key.
This is already technically possible if you modify your browser with either an addon, a proxy service, or assigning zeronet to be a service for protocol handling. See my protocol test site.
http://zero/<address> links currently seem to be more common due to the .pac file and chrome extension addon both quickly adding support with no real issues. I've written some code to have a workaround for zero:// links, but they're currently routed through the kaffie.bit domain if you register the protocol there.
The big issue seems to be that browsers don't want to play nice. Most reserve custom protocols for external software. And there's no easy way and ubiquitous way of assigning a protocol to a particular app. I also seem to have difficulty linking it to a python script (ZeroNet) rather than the OS's native style apps.
A custom browser could be made, but then you'd require people to use it. And it's unfortunately an on-going problem that doesn't yet have a clean solution. But as of now, you can configure your browser to do both methods and share this information with others.
The Profile/1GrEenUGRWnzaNZjR3XsQa6dQgdPDTyt7i/1PPVb3FDDiNyNqbdb5UAv8ykEC1K1Nwquy/[email protected] could be shortened since we already trust zeroid.bit to maintain a list of IDs mapping to key. zeroid.bit could also maps hub address to key.
As for this... That's not really possible. Pushing hub tracking onto zeroid not only monopolizes zeroid (the exact opposite of the point of zeronet) but it also puts weird restraints on merger sites.
The hub for a particular user is already listed in a directory site. And, in fact, the hub marker in the url is entirely unneeded. You can simply have the code check the user folder, see the hub marker, and then grab the user data from the right hub. The userid is also unneeded in the url. Really all you'd need is Profile/[userid]. Or shortened further, literally just the userid without 'profile'.