why the existing JSON formats

dcreemer

Hi-

I suspect I know the answer ... but why the variation in the structure of the JSON responses? The output of a Login vs. a Password vs. a Server or Credit card seems to be structured quite differently. Eg.:

$ op item xxxx | jq
{
"fields": [
{
"value": "me@server.com",
"type": "T",
"name": "Username",
"designation": "username"
},
{
"value": "my-password",
"type": "P",
"name": "Password",
"designation": "password"
}
]
}

$ op item xxxx | jq
{
"notesPlain": "this is the note",
"password": "m-password",
"sections": [
{
"title": "Related Items",
"name": "linked items"
}
]
}

$ op item xxxx | jq
{
"notesPlain": "some notes.",
"sections": [
{
"title": "",
"name": "",
"fields": [
{
"k": "string",
"n": "url",
"v": "http://example.com/",
"t": "URL"
},
{
"k": "string",
"n": "username",
"v": "me",
"t": "username"
},
{
"k": "concealed",
"n": "password",
"v": "my-password",
"t": "password"
}
]
},
...

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided

svondutch

@dcreemer Good question! What you're looking at are the decrypted item details that only our clients ever get to see (because our server has zero knowledge, does not have your keys, and only ever gets to see ciphertext).

The 1st item above is a Login item. I recognize that because it contains (web form) fields[]. The 2nd item above is a generated password item, because it contains a top-level field named password. All items have (custom) fields in sections[] and that is why the last item above could be anything. There is some legacy reasoning behind why-things-are-the-way-they-are that I will not try to bore you with :)

Sometime in the future, we will (A) document these for you, or (B) introduce some sort of abstraction that will give you an alternative to going the jq route on these structs.

rickfillion

or C) introduce whole new formats that are more obvious.

Rick