Feature: Import/export identity

To be able to use firestr on multiple computers, it would be great from a usability perspective if one could import/export one's cryptographic identity via the GUI.

[mempko]

This is definitely a great a great idea and would improve the usability a lot.

This is always a challenge for a p2p system without a central identity management system. I haven't figured out a good way to do it as there are big problems to overcome.

1. When you switch to one machine to another, how does a person connected know automatically connect to where you are now?
2. What happens when two machines are running at a time and you are away from them and someone starts a conversation, which machine should the conversation be part of?
3. Should apps and conversations be synchronized across all instances of your identity?

Centralized systems solve this problem by having one place where all your data is and knowing when you log into one machine or another. Distributed decentralized systems it becomes harder.

Your virtual identity is different than your physical identity, but from a usability perspective you want it to travel with you, like your real physical self does.

One solution I came up with is what if you had a usb key that stored your identity and apps and firestr in a self contained fashion. You just plug your stick in the machine and go... That way you never have two instances running with your identity and it follows you wherever you go.

[skwerlman]

What if instead of importing/exporting the main identity, it created a superficially similar child identity? Because the main identity would know all of its child identities (it created them), it could automatically distribute them. When a client sent a message to any of someone's related identities, instead of treating them separately, it could iteratively send messages to both the main identity and all its children.

[mempko]

@skwerlman This is actually really clever. If the parent identity is used as the keeper of the state, as in the single writer, then this would solve many problems with distribution. The only downside is that the parent identity would have to be online for this to work, which can be an ok tradeoff.

Since firestr does now detect when the user is idle, this can be used to direct traffic to the identity that is active.

I think there needs to be more thinking here, but I like your suggestion @skwerlman

[skwerlman]

My (poorly worded, 4am) thought was more along the lines of the parent advertising its children to known contacts, and having messages meant for the parent be sent to its children also. This way, the parent only needs to be online at the same time as their contacts once; after that, all messages are sent to all children, and no knowledge of who is active is necessary.
As a side effect, this allows a user to use two clients at once and receive messages on both, making it feel a bit more like a centralized service.

[mempko]

@skwerlman Ok, I see what you mean. So the child parent relationship is client/server. This is an intriguing idea.