Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to rename contacts exhaustively #7

Open
angelo-v opened this issue Mar 26, 2024 · 7 comments
Open

How to rename contacts exhaustively #7

angelo-v opened this issue Mar 26, 2024 · 7 comments

Comments

@angelo-v
Copy link
Contributor

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

  • the vcard:nameEmailIndex
  • the group documents of every group the contact is member of

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
Copy link
Member

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

@angelo-v
Copy link
Contributor Author

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

@csarven
Copy link
Member

csarven commented Mar 26, 2024

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants