solid / contacts

Client-client specifications of contacts data for people and organizations
MIT License
6 stars 1 forks source link

How to rename contacts exhaustively #7

Open angelo-v opened 5 months ago

angelo-v commented 5 months ago

The contact name (vcard:fn) is not only present in the contact document, but also in several other documents:

Since there is no backlink from the vcard:Individual to the address books and groups it is part of, one can not fully rename a contact by just knowing it's URI. This would only allow to change the name in the contacts own document, but not in the other places.

I wonder if a solid client-to-client spec for contacts should require those backlinks, to make it easier to rename a contact. If not, how else should client applications ensure that those indexes get updated eventually?

How does SolidOS contacts-pane handle this problem?

The contacts pane loads an address book and all the groups to the local rdflib store initially, when opening an address book. Therefore at the time of a renaming all documents are present in the store and rdflib can update all statements with the contacts name.

However, if SolidOS renames an Individual outside of the contacts-pane, the address book indexes and group documents do not get updated.

elf-pavlik commented 5 months ago

What is the reason for duplicating the name in multiple places, rather than using a reference like WebID?

angelo-v commented 5 months ago

Those are index documents, so you can make a list of people's names without dereferencing all of the contact documents first

csarven commented 5 months ago

Generally: it is not that the WebID shouldn't be used directly to get a hold of the authoritative and most up to date name. That of course makes sense. There is value in having a copy/cache closer to the application with less trips, so cheaper. There is also a related case where the display name of a contact may be custom to the addressbook holder.

elf-pavlik commented 5 months ago

Those are index documents, so you can make a list of people's names without dereferencing all of the contact documents first

Why not have an indexing agent that subscribes to all the contacts and updates the relevant index when the source contact changes? It sounds messy to expect apps to update some indexes if they are present.

We had some presentations about indexing during the last few CG calls, as well as some work we'll be discussing with Solid Practicioners during their next meeting.

Generally: it is not that the WebID shouldn't be used directly to get a hold of the authoritative and most up to date name.

This can lead to security issues. The user should control how they name others in their social graph. If I change my name to "Sarven Capadisli" in my WebId Document and use a copy of your avatar, it shouldn't just change automatically in everyone's address books. This is a separate topic.

angelo-v commented 5 months ago

Why not have an indexing agent that subscribes to all the contacts and updates the relevant index when the source contact changes?

Can you explain what an indexing agent is? Is it described somewhere? Is it something on the server side, or something a client side data-module could implement?

It sounds messy to expect apps to update some indexes if they are present.

That's why we are providing data-modules to keep track of all such things

elf-pavlik commented 5 months ago

Since we want to keep the resource server simple and generic, I see a need for various bots that act as solid clients but run independently from it. One could be an indexing bot, which would manage all kinds of different indexes.

This repo has no spec draft; it only has some shapes. It is hard to know what requirements this index is supposed to address. How can we even evaluate if the approach taken by SolidOS isn't a premature optimization?

angelo-v commented 5 months ago

These are good questions and I cannot answer them. Perhaps @timbl can help us out, I think SolidOS implements his ideas so far. I would like to see a a draft spec coming up, clarifying those questions and see what we actually need.