etesync / android

EteSync - Secure, end-to-end encrypted, and privacy respecting sync for your contacts, calendars and tasks.
https://www.etesync.com
GNU General Public License v3.0
296 stars 33 forks source link

Etesync altering contacts upon sync #244

Open gitmeED331 opened 1 year ago

gitmeED331 commented 1 year ago

Edit: additional upstream ticket created: https://github.com/bitfireAT/vcard4android/issues/22

=======

I have encountered an issue where Etesync is altering my contacts and screwing up address book organization and addresses.

The first part of the issue I noticed was how Etesync copies the business/company/organization to fill in the first/middle/last names (which are intentionally blank).

The second part of the issue is that Etesync is taking the address and corrupting/malforming it.

Example, lets say I create a contact for XYZ Medical Center

The contact I enter: First name: [blank] Middle name: [blank] Last name: [blank] Company: XYZ Medical Center Phone: 123.456.7890 Address: 123 John Doe Dr City: Tampa State: Florida Zip code: 12345

What Etesync does and screws up my address book on my devices: First name: XYZ Middle name: Medical Last name: Center Company: XYZ Medical Center Phone: 123.456.7890 Address: [blank] PO Box: 123 John Doe Dr,Tampa,Florida,12345 City: [blank] State: [blank] Zip code: [blank]

This is not acceptable for multiple reasons.

  1. it is screwing up the organization of my address book
  2. It is editing my stuff without my knowledge or permission, against my will
  3. It is screwing up my contact addresses.

I am running stock on Pixel 6A (latest update). I have tried multiple contact apps and the Etesync WebApp to correct things and Etesync keeps screwing things up.

I know it has to be Etesync since I can edit the contacts and things will work just fine until the next sync. Also, if I use other options like DecSync, there is no issue. The issue only exists when Etesync is involved.

What is going on? What can be done to fix this?

Thank you

barathrm commented 1 year ago

Hm, I can't reproduce this behavior.

I tried reproducing this by creating a contact using the default contacts app on my phone similar to your description above. Ie, I left the name fields blank and only filled out the company, phone and location fields. I don't have an "address" field when creating a contact, only "location".

I manually synced my contacts using the etesync android app and then looked at the contact on my linux PC. The contact there looks exactly as I created it. Looking at the transaction entry in the etesync app, it also looks as expected. This is the raw data stored in etesync:

BEGIN:VCARD
VERSION:4.0
PRODID:-//EteSync//com.etesync.syncadapter/2.4.3 ez-vcard/0.11.2
UID:4e155387-24cd-4910-9537-41acb9d41c0b
FN:My Test Company
ORG:My Test Company
TEL;TYPE=cell:123456789
ADR;TYPE=home;LABEL=Blabla\nCity\nState\n1234:;;Blabla\nCity\nState\n1234;;
 ;;
REV:20230826T105858Z
END:VCARD

You could also create a testing non-etesync-backed contact in the way that would break your etesync sync, and then export it as a vcard file and upload it here. Then others could try importing/inspect it to see if your contacts app maybe produces a contact which etesync somehow cant parse.

gitmeED331 commented 1 year ago

Actually, even yours is messed up. Your example contains data in the FN (full/formal name) field. Also, your "single address field" is also an indicator of problems.

I will do you one better. Here is a video ( https://u.pcloud.link/publink/show?code=XZBxAaVZNT3aERFki0yLuSLDPfhrefo6YJFX ) from start to finish of creating a contact using a brand new etesync contact list, ending with showing how things end messed up.

Here is the raw data from this new contact seen in video without any additional edits post video: BEGIN:VCARD VERSION:4.0 PRODID:-//EteSync//com.etesync.syncadapter/2.4.3 ez-vcard/0.11.2 UID:8084b7be-5966-4a8b-9efe-4e86ab916a24 FN:XYZ Medical Center   <-- (assuming this is "Full/formal Name", this should be blank since there is no name, confirmed later as seen below) ORG:XYZ Medical Center TEL;TYPE=cell:1123.456.7890 ADR;TYPE=home;LABEL="123 Elm St\nTampa, FL 12345\nUSA":;;123 Elm St;Tampa;FL;12345;USA REV:20230826T133752Z END:VCARD

Note: the address is also messed up

This was created in the stock contacts app. I have also tried doing things using the OpenContacts app, Simple Contacts Pro app, etc. and the exact same thing happens.

  1. I would try to use my iPAD, but Etesync is rather useless and horrible on iOS/iPADos (sorry, but the app and such is pretty bad Etrsync sucks on iOS/iPadOS because of Apple, not the other way around, though it doescrash alot and fail to sync)
  2. I did try on my stock android tablet (which is running Android 11 Go edition) using the stock google contacts app to the same results.
  3. Using the etesync web portal, I notice a couple variences:

to use the web portal is not a solution for obvious reasons, but especially since even that is messed up.

Here is the original raw data from a contact made via the web portal before any edits/corrections:

BEGIN:VCARD PRODID;VALUE=TEXT:-//iCal.js EteSync Web VERSION:4.0 UID:2677878a-c69b-4114-bef0-984633450f0f REV;VALUE=DATE-TIME:20230826T082755 FN: N:;;;; TEL;TYPE=home:908.765.4321 ADR;TYPE=home:456 my street\nDenver\, co\n12345 IMPP;TYPE=jabber:jabber: ORG:Play House Club END:VCARD

Here is the same contact after trying to correct the address field via device (interestingly, it removed the jabber stuff):

BEGIN:VCARD VERSION:4.0 PRODID:-//EteSync//com.etesync.syncadapter/2.4.3 ez-vcard/0.11.2 UID:2677878a-c69b-4114-bef0-984633450f0f FN:Play House Club ORG:Play House Club TEL;TYPE=home:908.765.4321 ADR;TYPE=home;LABEL="456 my street\n456 my street\nDenver, co\n12345\nDenver, CO 12345":456 my street\nDenver\, co\n12345;;456 my street;Denver;CO;12345; REV:20230826T145254Z END:VCARD

here is a link to a vcard not associated with etesync: https://u.pcloud.link/publink/show?code=XZ8qAaVZAHhd7YGfXBF6I5JaMRs2zbE7toz7

barathrm commented 1 year ago

Thanks for the details!

I agree, I also had the FN field added. I just didn't notice, because non of my apps seem to show that as a "name" field. Ie. the contact is shown as nameless both on android and linux :thinking: But yes, it seems to be added by etesync, creating a plain contact and exporting it doesn't have that field. It also seems like etesync adds this "TYPE" thing and a LABEL to address.

As a test I created a contact with no name but an address in linux and it got imported into etesync "correctly", ie no FN field was added. The address looks as I would expect too I think:

BEGIN:VCARD
VERSION:3.0
ADR;TYPE=home:Some PO;;Some Street;some locality;some region;Some postal co
 de;Denmark
N:;;;;
ORG:Some Business
UID:8b965130-a6fe-48d7-ba98-e6e181661150
END:VCARD

So maybe the android adapter has some issues.

Also, your "single address field" is also an indicator of problems.

I have no knowledge at all about vcard standards, but that's just how my android contacts app displays it (ie as only one item). So I dont think that in itself has anything to do with etesync, at least on my side.

Every edit via web portal adds another "jabber:" despite no jabber ever being put in.

that's bad... sounds like a bug for https://github.com/etesync/etesync-web

here is a link to a vcard not associated with etesync: https://u.pcloud.link/publink/show?code=XZ8qAaVZAHhd7YGfXBF6I5JaMRs2zbE7toz7

I imported this to both my etesync address book and my local phone account. The etesync import changes it similar to yours. Ie, FN is set and the address isn't duplicated exactly, but it seems like etesync adds something called LABEL, while keeping the rest of the address as before. I assume that's why it's still displayed correctly. At least on my phone and on linux the contact is displayed correctly, with only one address and without a name.

Your original vcf file:

ADR;HOME:;;123 NoWhere Lane;NoWhere;NY;12345;USA

After importing to etesync

ADR;TYPE=home;LABEL="123 Elm St\nTampa, FL 12345\nUSA":;;123 Elm St;Tampa;FL;12345;USA

seems to seems to have kept the address as is (?), but turned HOME into a TYPE (whatever that is) and added LABEL="123 Elm St\nTampa, FL 12345\nUSA". :shrug:

I watched your video and yeah, it looks like your contacts app is automatically displaying the value of FN as the first and last names etc. That doesn't happen for me, weirdly enough:

It seems like my contacts app stores first and last names under the N attribute as two fields, and only displays them as first/last names if they're stored under N, not if they're only stored under FN.

I have no idea what the right behavior is, but I tend towards agreeing that ideally the android etesync adapter app shouldn't change the contact vcard from what the android contacts app generated. This is the first time I've heard of this issue, so maybe most apps simply don't render FN fields as first/last names, but only as a kind of label in the list of contacts? And the LABEL also seems to be parsed differently.

Unless someone else beats me to it I'll try to see what the code does. The etesync android app uses a library to handle the vcard stuff, and this might be a bug/weird behavior.

barathrm commented 1 year ago

Alright, here's the vcard standard (I think):

https://datatracker.ietf.org/doc/html/rfc6350

About FN, which is added by etesync:

Purpose: To specify the formatted text corresponding to the name of the object the vCard represents. Value type: A single text value. Special notes: This property is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object.

From this, it sounds like, according to the standard, a vcard must have a FN property. From reading this I assume the FN property's purpose is to allow apps to read one single text property to display an item as, like in a list of contacts. So it makes sense that the contacts-handling library used by etesync would add this if it's missing, to make sure the vcard conforms to the spec.

About LABEL, wrt. to the ADDRESS property:

Purpose:
    To specify the formatted text corresponding to delivery address of the object the vCard represents. 
Value type:
    A single text value. 
Special notes:
    The property value is formatted text that can be used to present a delivery address label for the vCard object. The type can include the type parameter "TYPE" to specify delivery label type. The TYPE parameter values can include "home" to indicate a delivery label for a residence; "work" to indicate delivery label for a place of work; and "pref" to indicate the preferred delivery label when more than one label is specified. These type parameter values can be specified as a parameter list (i.e., "TYPE=home;TYPE=pref") or as a value list (i.e., "TYPE=home,pref"). The default is "TYPE=work". 

So, this seems a bit similar. The purpose seems to be to provide a string which can be used by an app to summarize or display an address "as one thing". Ie. an address might consist of individual sub-items like street, city etc, but this might tell an app what to print when the address is supposed to be summarized somehow.

Sooo... from the above, it sounds like adding FN and LABEL are either correct or even required.

I have also tried doing things using the OpenContacts app, Simple Contacts Pro app, etc. and the exact same thing happens.

Yeah, I must've tested editing my vcard before syncing or something. I get the same behavior in my apps now. I think that's either it's bug in all these contacts apps though, since that's not what FN should be interpreted as according to the spec, or the vcard spec simply isn't really designed for organizations / cases where you want to make a vcard for an entity which has no first/last name. I'll google some more when I have time, maybe there's some fun obscure history on this or it's case of "the spec says this but everybody does that"...

Edit:

So I went a bit further down the rabbit hole and I think what's happening might be this:

The vcard spec has a KIND property which can be set to invidual, org, group etc. individual is the default. I quickly searched through the vcard library's source code and I only saw references to the group KIND. I assume this means that there's no support for the org kind. I also tried creating an org kind of contact in my contact app, but I don't think that's even possible? And googling whether this is something that's usually supported didn't give me a lot...

I think what might be going on is that the vcard library adds the FN field, since it's required according to the spec, and every app assumes that a vcard without KIND specified is KIND:invidual as written in the spec. Then, apps interpret FN as an invidual's name, since that's what the vcard represents (they think). org might be meant to fix this, but I haven't been able to find any app that supports it so far. I tried importing the following vcard manually, taken from the spec as an example:

BEGIN:VCARD
VERSION:3.0
KIND:org
FN:ABC Marketing
ORG:ABC\, Inc.;North American Division;Marketing
END:VCARD

But, even if I import this to my local address book (without involving etesync) it displays FN as the first and last names. Simple Contacts shows it a bit differently, but it also drops KIND. Maybe no apps actually support this?

gitmeED331 commented 1 year ago

Hmm, that is strange since using these apps alone or synced to gmail, outlook, Icloud and other providers have no issue. I literally had no problem using just the org field with no FN (corrected down below) until i started using etesync, then there is DecSync that also has no issue.

i saw another issue ticket here that mentioned the single address fiels should be seperate fields issue and all my apps use separate address fields, including my desktop clients.

I don't understand how vCard expects people to store businesses that are not related to a specific person if it is not allowing this.

Is cardav and vcard separate standards? If so, maybe these apps (which would include Google, iCloud, Outlook, etc themselves) use the cardav standards?

When I import that vCard, I get this: ABC, inc Screenshot ← github doesn't like my image link apparently, so I included it directly

https://u.pcloud.link/publink/show?code=XZdTNaVZuo9gKiMIicSd9RmLv08JRmDN4K27

i looked up samples of vCards and they show separate address fields. https://www.w3.org/TR/vcard-rdf/#Examples

I just noticed something about the vCards and don't think it is the FN field that is the problem, but rather etesync's usage of it and lack of a blank N field.

For an organization with no N field input:

BEGIN:VCARD
VERSION:3.0
FN;CHARSET=UTF-8:ABC Money Management
N;CHARSET=UTF-8:;;;;
TEL;TYPE=WORK,VOICE:123.456.7890
ADR;CHARSET=UTF-8;TYPE=HOME:;;123 Walnut Dr;Denver;CO;12345;USA
ORG;CHARSET=UTF-8:ABC Money Management
REV:2023-08-26T22:19:23.073Z
END:VCARD

For a personal contact:

BEGIN:VCARD
VERSION:3.0
FN;CHARSET=UTF-8:John Doe
N;CHARSET=UTF-8:John Doe
TEL;TYPE=WORK,VOICE:123.456.7890
ADR;CHARSET=UTF-8;TYPE=HOME:;;123 Walnut Dr;Denver;CO;12345;USA
ORG;CHARSET=UTF-8:ABC Money Management
REV:2023-08-26T22:19:23.073Z
END:VCARD

I think the FN is supposed to be populated based on priority of attributes, not directly entered. So that if first/middle/last name are entered, FN uses that attribute; but if they are empty the FN field uses the Organization field; etc down the list of titling type attributes. And since the N attribute is missing and FN is being misused, it copies the Org attribute to fill the gap. This is just me guessing with what little knowledge I have on the subject and deduction from the behavior.

gitmeED331 commented 1 year ago

Running some more comparisons, I think my deduction may be correct. I signed up for Purelymail (just to see what it has to offer) and created a contact.

One thing they do is display the FN attribute (titled "display name" on the interface) and made it user selectable/editable (not many offer this as a direct editable).

Here is the behavior presented: If this FN field is left blank and no N attribute filled in, but the Org is filled, it copies the Org attribute to the FN attribute, leaving the N attribute blank. If the FN field is blank and both N and Org attributes are filled, it copies the N attribute to the FN attribute.

See video: https://u.pcloud.link/publink/show?code=XZBRaaVZTaogHR9Uk4bb2ovu1r8kNkItA1iV

I believe this is the correct behavior that Etesync is not following but the apps are.

vCard from the 3 versions:

Org attribute only:

BEGIN:VCARD
VERSION:3.0
UID:sabre-vobject-35e0699c-9a91-4718-917a-3cdb69bbfe91
PRODID:-//MStilkerich//RCMCardDAV v5.0.1//EN
REV:2023-08-27T04:50:56Z
N:;;;;
ORG:NoWhere Motel Inc
FN:NoWhere Motel Inc
X-ABSHOWAS:COMPANY
TEL;TYPE=home;TYPE=voice:123.455.4533
ADR;TYPE=home:;;123 Fake St;NoWhere;NY;12323;USA
END:VCARD

N attribute only:

BEGIN:VCARD
VERSION:3.0
UID:sabre-vobject-d73fab2e-a353-4e30-aca4-bcf063db189a
PRODID:-//MStilkerich//RCMCardDAV v5.0.1//EN
REV:2023-08-27T04:51:41Z
N:Doe;Jane;;;
FN:Jane Doe
TEL;TYPE=home;TYPE=voice:123.124.1245
ADR;TYPE=home:;;123 Fake St;NoWhere;NY;12343;USA
END:VCARD

Org and N attributes:

BEGIN:VCARD
VERSION:3.0
UID:sabre-vobject-d79ef48f-d1f0-4901-acfe-a029dad0f0b8
PRODID:-//MStilkerich//RCMCardDAV v5.0.1//EN
REV:2023-08-27T04:53:02Z
N:Doe;John;;;
ORG:NoWhere Motel, Inc
FN:John Doe
TEL;TYPE=home;TYPE=voice:123.123.1234
ADR;TYPE=home:;;123 Fake St;Nowhere;NY;12343;USA
END:VCARD

I imported these vCards into a newly created Etesync contact list. Besides the address getting messed up on all of them, The Org only vCard is the only where it copies the Org attribute to the N attribute, which Etesync seems to see FN and N attributes as one and the same which it shouldn't.

NOTE: in order for me to import all 3, I had to change the name on the N Only vCard to "Jane Doe" (hence the variance in the supplied vCards and the video). The apps couldn't tell the difference between the ones with the N attribute filled on import and merged them, duplicating fields.

barathrm commented 1 year ago

I was a bit confused by what you meant was the problem with the FN field and how etesync uses it, but here's my take:

I think the FN is supposed to be populated based on priority of attributes, not directly entered.

If you mean "directly entered by a human", then yeah, I think that's what etesync does. :thinking: Ie it sets the FN field automatically based on what/whether there's something in N, ORG etc. And then apps display that FN field.

Here is the behavior presented: If this FN field is left blank and no N attribute filled in, but the Org is filled, it copies the Org attribute to the FN attribute, leaving the N attribute blank. If the FN field is blank and both N and Org attributes are filled, it copies the N attribute to the FN attribute.

I think etesync does that as well? That's why when you don't set a N, etesync takes the ORG and puts it into FN.

The Org only vCard is the only where it copies the Org attribute to the N attribute

Alright, so I've experimented a bit with this and read some more of the library's code. It seems that the library is adding an N field only if the vcard version is 3.0, as it's mandatory in that case. For 4.0, it doesn't do that, but creates an empty field instead.

I've experimented what happens depending on whether FN already exists in a vcard or not. The procedure I followed was import using app, sync using etesync, then inspect raw vcard in etesync app.

Without FN:

BEGIN:VCARD
VERSION:4.0
ORG:Test Company
END:VCARD

Then, no matter the import-app I get this:

BEGIN:VCARD
VERSION:4.0
PRODID:-//EteSync//com.etesync.syncadapter/2.4.3 ez-vcard/0.11.2
UID:07ee0d96-a841-4952-a841-e42ced4b13dc
FN:Test Company
ORG:Test Company
REV:20230827T101047Z
END:VCARD

So it adds the FN field as expected and according to the spec.

With FN:

BEGIN:VCARD
VERSION:4.0
ORG:Test Company
FN:Test Company
END:VCARD

Imported using default contacts app:

BEGIN:VCARD
VERSION:4.0
PRODID:-//EteSync//com.etesync.syncadapter/2.4.3 ez-vcard/0.11.2
UID:55980cf8-a0f9-46f3-bb09-4d42c979c736
FN:Test Company
N:Company;Test;;;
ORG:Test Company
REV:20230827T101820Z
END:VCARD

Imported using Simple Contacts:

BEGIN:VCARD
VERSION:4.0
PRODID:-//EteSync//com.etesync.syncadapter/2.4.3 ez-vcard/0.11.2
UID:9706ef88-bae9-48be-a1ec-0365618845ac
FN:Test Company
ORG:Test Company
REV:20230827T102214Z
END:vCard

So it seems like my default android app might be adding the N field. Maybe you can confirm this.

However, the ultimate issue of the first and last name fields in apps being populated based on the FN property still seems to happen, in both apps, as long as the FN property is present. And since it needs to be present according to the spec, I don't know what we should do about that. One work-around for users would be to set the first and last names to one space character each, but that might screw with UI's which expect the values there to actually mean something 🤷

gitmeED331 commented 1 year ago

Yeah, I was generally wrong about the FN field. I originally thought the FN field was the N field. Now I understand it is not, so why is N getting populated when synced with Etesync?

I almost thought it might have something to do with vCard version because Google Contacts app exports version 2.1, OpenContacts and Etesync export version 4.0; but that doesn't appear to be an issue.

It seems like my contacts app stores first and last names under the N attribute as two fields, and only displays them as first/last names if they're stored under N, not if they're only stored under FN.

This is correct behavior.

One work-around for users would be to set the first and last names to one space character each, but that might screw with UI's which expect the values there to actually mean something

If you do that the apps will show "(No Name)" and really mess things up more.

However, the ultimate issue of the first and last name fields in apps being populated based on the FN property still seems to happen, in both apps, as long as the FN property is present. And since it needs to be present according to the spec, I don't know what we should do about that.

From my standpoint it is only happening in relation to Etesync since none of my other tests without Etesync are doing it (seen below).

Somehow have to stop it from copying the FN to N field in the absence of the N field. I know, sounds simple but not, its the how that needs to be figured out.

I created this vCard and imported it into Etesync, DecSync, Gmail, and phone Storage.

BEGIN:VCARD
VERSION:4.0
ORG:Test Company
N:;;;;
FN:;;
END:VCARD

Was hoping "blanking" out the FN and N fields it would help, but as you can see below it doesn't. When it imports initially, the apps treat it appropriately until sync with Etesync.

The apps export looks like this before Etesync syncs, they trimmed the blanks:

BEGIN:VCARD
VERSION:2.1
ORG:Test Company
END:VCARD

Once Etesync gets it before sync, its raw looks like, so before sync Etesync has already changed things:

BEGIN:VCARD
VERSION:4.0
FN:Test Company
ORG:Test Company
END:VCARD

Then once Etesync syncs it with server, the Etesync vcard looks unchanged but the app export looks like this:

BEGIN:VCARD
VERSION:4.0
PROID:ez-vcard 0.11.3
ORG:Test Company
N:Company;Test;;;
FN:Test Company
TITLE:
END:VCARD

Imported into DecSync contact list, everything looks appropriate, I get this export (exactly like the original):

BEGIN:VCARD
VERSION:4.0
ORG:Test Company
N:;;;;
FN:;;
END:VCARD

Imported into Gmail or phone storage, apps look appropriate, exports get this (same from both apps):

BEGIN:VCARD
VERSION:4.0
PROID:ez-vcard 0.11.3
FN:
N:;;;;
ORG:Test Company
TITLE:
END:VCARD

The export from GMail web looks like this:

BEGIN:VCARD
VERSION:3.0
item1.ORG:Test Company
item1.X-ABLabel:work
CATEGORIES:myContacts
END:VCARD

So, it is not the apps copying things to the FN and N fields.

I hope this helps, I don't know what else I can provide except to test things for you.

barathrm commented 1 year ago

So, it is not the apps copying things to the FN and N fields.

I agree about FN, but I'm not sure about the N property, since I didn't get a N added in the etesync vcard raw text unless importing the vcf file with the default android app. So to me it looks like apps are introducing various behaviors. Of course, that behaviour might somehow differ between backends... not sure why, but :shrug:

Once Etesync gets it before sync, its raw looks like, so before sync Etesync has already changed things:

so it looks like at this point you already get the FN property.

Then once Etesync syncs it with server, the Etesync vcard looks unchanged but the app export looks like this:

So the vcard looks unchanged, and without a N, in the etesync raw data tab? That would indicate to me that etesync doesn't add the N, but that the app does.

From your exports above it looks like gmail and decsync both don't touch the FN property, even though it's empty in your original vcard, while the library used by etesync does. When it sees that the FN property is empty and it sets it based on what's in the org property. I guess that's the reason it might look differently in the apps, ultimately.

Whether this is correct or not, I don't know. Just from reading the spec I can see someone arguing that the etesync library does it correctly, since the spec says it must be present have have a single text value (ie not empty). But... it seems like google doesn't care. And google is big enough to maybe enforce their bend on the standard, which means that apps treat FN = first and last names etc, when present and not empty.

We could make an issue ticket for this upstream (https://github.com/bitfireAT/vcard4android) or patch this in our version of the library, but it's not really up to me and I'm not sure what the correct thing to do is. But I'm not even a maintainer :D Anyways, thanks for helping debug :pray:

Maybe @tasn has an opinion on the correct behavior, but it sounds like a ticket at the upstream repo might help more since I assume that dev has more domain level knowledge on this.

gitmeED331 commented 1 year ago

so it looks like at this point you already get the FN property.

Yes, but only after interacting with Etesync, nothing else.

Something else I noticed: Proton treats the FN and N attributes as one and the same (really it ignores the existence of the N attribute completely) and requires the FN attribute to be filled. Won't even allow a contact to be created/imported without FN attribute.

So the vcard looks unchanged, and without a N, in the etesync raw data tab? That would indicate to me that etesync doesn't add the N, but that the app does.

But why only when interacting with Etesync? I think it is multistep: at first interaction with Etesync, it adds the FN as it should; the next interaction (the sync) it adds the N? But then once the N is there, regardless of where it came from, why is Etesync not showing it in its raw data?

But if it was the apps adding the FN and N attributes, why wouldn't they do it with DecSync? It's only happening with Etesync.

Which I guess DecSync does not do any processing, merely manages the contact list files for syncthing to transfer the raw data. Which would explain why it doesn't have the issue.

it seems like google doesn't care. And google is big enough to maybe enforce their bend on the standard, which means that apps treat FN = first and last names etc, when present and not empty.

Well, we know Google does whatever they want, no regard for anything or anyone.

I will look into upstream.

barathrm commented 1 year ago

the next interaction (the sync) it adds the N? But then once the N is there, regardless of where it came from, why is Etesync not showing it in its raw data?

I'm pretty sure that if etesync isn't showing it in the raw data, it's not there. In other words, if it's there when exporting it using an app, but not in the etesync data, I think it's added by the app...

But if it was the apps adding the FN and N attributes

If I understand the code and our experiments correctly, etesync only adds the FN property. But then apps might add the N property as well, once they see the FN property, like my default contacts app (but not Simple Contacts).

Which I guess DecSync does not do any processing

Yep, I'd guess DecSync doesn't add the FN, and then the rest of the problems don't get kickstarted by that.

gitmeED331 commented 1 year ago

But if the apps are adding the N, why aren't they doing it with DecSync and others? It only occurs with Etesync.

So, maybe is the interaction between the apps and etrsync. The combination is the issue.

gitmeED331 commented 1 year ago

Upstream ticket created: https://github.com/bitfireAT/vcard4android/issues/22

barathrm commented 1 year ago

But if the apps are adding the N, why aren't they doing it with DecSync and others? It only occurs with Etesync.

If I understand correctly, etesync adds the FN, and then android apps add the N because of that. So my guess is that DecSync doesn't add FN, so in that case the android apps don't add N. But, even with no FN, my android apps show the first / last names from FN. So it's not easy to decide what's right imo.

gitmeED331 commented 1 year ago

Yeah, definitely hard to pinpoint.

gitmeED331 commented 1 year ago

Just went through and managed to get Etesync working on my iPAD and my wife's iphone

Same behavior is seen not seen before Etesync, independent of android involvement (meaning not the same address books or account)