Add PrimaryIdentity() to App #130

sarah · 2018-10-04T04:37:55Z

sarah commented

2018-10-04 04:37:55 +00:00

It was getting annoying looping through all available peers even though I knew there was only one. This treats the first discovered profile as the primary profile.

buildbot commented

2018-10-04 04:45:31 +00:00

Drone Build Status: success

https://build.openprivacy.ca/cwtch.im/cwtch/165

Drone Build Status: success https://build.openprivacy.ca/cwtch.im/cwtch/165

dan commented

2018-10-04 20:44:04 +00:00

i don't really love the assumptions this adds to app tho, that there is a thing as a primary identity, it's not settable. we technically support multiple passwords, this is password order dependant

how often were you having to loop? couldn't you just store the onion for access via Get() ? or is this on load in some places? what about

seems like either we should consider a change to List to return onion:profile instead of onion:name

or just a list of onions so you could

app.GetPeer(app.List()[0])

or just a list of profiles

(wow go maps are a bit clunky and theres no way to get the keys without a loop? awkward)

i don't really love the assumptions this adds to app tho, that there is a thing as a primary identity, it's not settable. we technically support multiple passwords, this is password order dependant how often were you having to loop? couldn't you just store the onion for access via Get() ? or is this on load in some places? what about seems like either we should consider a change to List to return onion:profile instead of onion:name or just a list of onions so you could app.GetPeer(app.List()[0]) or just a list of profiles (wow go maps are a bit clunky and theres no way to get the keys without a loop? awkward)

sarah commented

2018-10-04 21:57:40 +00:00

I'd argue that the assumption of a primary identity (being the first one you created) is valid. Agreed this is password order dependent, and something we should consider when we approach designing deniable profiles.

The use case this comes up for is primarily apps built on top of Cwtch (and in particular non-gui / non-interactive apps i.e. command line tools where the assumption of 1 password, 1 profile, 1 identity holds) - in those cases looping through profiles / asking the user which onion they want to use etc. adds a lot of complexity.

I'd argue that the assumption of a primary identity (being the first one you created) is valid. Agreed this is password order dependent, and something we should consider when we approach designing deniable profiles. The use case this comes up for is primarily apps built on top of Cwtch (and in particular non-gui / non-interactive apps i.e. command line tools where the assumption of 1 password, 1 profile, 1 identity holds) - in those cases looping through profiles / asking the user which onion they want to use etc. adds a lot of complexity.

sarah closed this pull request

2018-10-05 20:12:22 +00:00