Thanks for providing this.

Regarding your first point. I've filed this feedback to our team in charge of the 1Password.com page. I don't have much more than that right now but I generally agree with you. There are probably reasons for why we focus this a bit differently... Notably, if I had to guess, that paying through IAP (which is how they'd likely end up paying if they sign up in app) costs us a significant amount more and offers far less flexibility. Just one potential reason I think.

For the second. We've rewritten this welcome screen multiple times... turns out getting it right is incredibly difficult. I think we've gone through something like 50 different variations of this single pane now. I honestly don't have anything on in mind that I can share here.. it's both frustrating for us because we know people are confused by it, but we also aren't sure how else we can present that information that's going to be more clear. It's always a teeter totter, trade one thing for something else, but we lose something as well. I do appreciate you commenting on this though, I'll pass it along to the rest of the team as well.

Station is one we don't generally recommend using in this way... First the blog post where we talk about this general concept: https://blog.agilebits.com/2013/03/06/you-have-secrets-we-do...

Then the quote from it that matters most:

> We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password. We aren’t casting aspersions on the integrity or competence of any developers, but we simply can’t advise otherwise.

So our general stance here is, you really shouldn't enter your Master Password/Secret Key into third party apps. We can't vouch for it and you're basically giving Station full access to your data doing this. Entering it into the CLI directly is great, but.. Station is gaining access to this information which is the issue we generally have with suggesting this type of thing.

Adding support for standalone vaults to our CLI is... difficult. The 1Password.com server is written in Go. As is the CLI. We were able to make the CLI in super fast form because we could piggy back on the code we have for the server, move a couple modules over to a new project, write some glue, wah-la. The CLI also started as a tool for management of accounts... think adding users, deleting users, adding vaults, granting access, etc. Admin type stuff. Literally none of this applies to standalone vaults.

At best we could write a CLI (separately) as part of the 1Password app that is in Objective-C/Swift, since we could piggy back on existing libraries we have in 1Password for Mac/iOS. But I really don't see very many people needing this... would it be cool? Absolutely... but... I don't think there's this great demand for it.

Regarding sudolikeaboss, I think we'd ultimately like to see something like that again. But the way sudolikeaboss worked was incredibly hacky and it was bound to break because of this. We'll have to take a look at this for future updates, but I don't see sudolikeaboss coming back as a thing, perhaps we can do something internally though. There was simply no time for this for 7.0 though. But maybe it's a neat idea for 7.1 or 7.2... both of which have some already huge features planned.

So to kind of re-iterate a little bit. The CLI exists because it was super easy to glue pieces together from existing code. It's not like we set out to write this to stick it to anyone, we wrote it because we seen a demand for it by administrators who were on unix type systems and they wanted ways to admin their accounts. It gained some editing/using features as well but those came after. Interestingly the CLI talks directly to the server for this, it doesn't have a copy of data locally... it doesn't really have any idea about data formats and such.

And sudolikeaboss, while cool, wasn't an officially endorsed product of ours... that isn't an excuse for breaking it, but it also shouldn't be a huge surprise that it did break due to the way it functioned. I personally would like to see something similar in the future though.

Hope that helps some... I understand these are all important to you though and I hope my response doesn't dismiss any of that importance. I'm only trying to explain from our side so you can see thought process a little bit. You also don't have to agree with our decisions, and I'm not trying to convince you that we did the right thing. I just find understanding why we do something makes it easier to at least accept how/why something happened.

Please do let me know if you have questions though. I'll keep an eye on this for a few more days. Otherwise, please email in and mention me and I'd be happy to help get you answers.

Kyle

AgileBits