People files as contacts #14

New Issue

Open

opened 2021-06-08 11:30:40 -05:00 by JadedCtrl · 1 comment

JadedCtrl commented

2021-06-08 11:30:40 -05:00

(Migrated from github.com)

People files could be linked to roster members, though the link might not be as strong as with IM Kit.

Each protocol has its presentable (and less presentable) names, e.g., "Jabber" and "jabber." If a person file is searched for a user identifier for a given protocol, the identifier would be stored in META:$protocolSignature, with the attribute's display name being $protocolName.

When a member is added to, loaded into, or edited in the roster, Caya should first check if there are any people files with the same user identifier; if there isn't, one should be created with as many slots (META:name, etc) filled out automatically as possible, and the file should marked as "created by Caya" with some attribute― let's say it's Caya:own.

If there is one already existent and has Caya:own, all attributes should be overwritten with their new values. If it doesn't have the Caya:own, it shouldn't be edited, with the only exception being the profile picture. If the file is empty (has no picture), then the avatar should be copied into the file.

New people files should be put in Caya's config directory somewhere― maybe Caya/People/― so as to not clutter the user's people folder.

Management of these files through Tracker shouldn't be supported with this basic implementation― if a person is deleted, then it'll just be recreated. That would be a little more tricky, and could be done in the future.

People files could be linked to roster members, though the link might not be as strong [as with IM Kit](https://www.eiman.tv/imkit/use.html). Each protocol has its presentable (and less presentable) names, e.g., "Jabber" and "jabber." If a person file is searched for a user identifier for a given protocol, the identifier would be stored in `META:$protocolSignature`, with the attribute's display name being `$protocolName`. When a member is added to, loaded into, or edited in the roster, Caya should first check if there are any people files with the same user identifier; if there isn't, one should be created with as many slots (`META:name`, etc) filled out automatically as possible, and the file should marked as "created by Caya" with some attribute― let's say it's `Caya:own`. If there is one already existent and has `Caya:own`, all attributes should be overwritten with their new values. If it doesn't have the `Caya:own`, it shouldn't be edited, with the only exception being the profile picture. If the file is empty (has no picture), then the avatar should be copied into the file. New people files should be put in Caya's config directory somewhere― maybe `Caya/People/`― so as to not clutter the user's people folder. Management of these files through Tracker shouldn't be supported with this basic implementation― if a person is deleted, then it'll just be recreated. That would be a little more tricky, and could be done in the future.

JadedCtrl commented

2021-07-26 10:04:28 -05:00

(Migrated from github.com)

On second thought― if a Person is deleted, it shouldn't be re-created.

There should be a distinction between Buddies and Contacts, like in libpurple: The first being a server-side/protocol-side "friend," associated specifically with that account and protocol, and the second being Cardie-side and represented in a Person file, capable of representing several buddies.

Individual protocols should store buddies themselves (sending to Cardie through the IM_CONTACT_LIST_* messages). It might be best for them to use the same paths as the avatar cache (which stores buddy avatars in $CONFIG/Cardie/Cache/Accounts/$ACCOUNT/People/) with attributes.

The protocol add-ons themselves shouldn't know about Contacts, that's Cardie's job, and they should be created manually by the user (selecting a or several Buddies to compose that Contact).

On second thought― if a Person is deleted, it _shouldn't_ be re-created. There should be a distinction between Buddies and Contacts, like in libpurple: The first being a server-side/protocol-side "friend," associated specifically with that account and protocol, and the second being Cardie-side and represented in a Person file, capable of representing several buddies. Individual protocols should store buddies themselves (sending to Cardie through the IM_CONTACT_LIST_* messages). It might be best for them to use the same paths as the avatar cache (which stores buddy avatars in $CONFIG/Cardie/Cache/Accounts/$ACCOUNT/People/) with attributes. The protocol add-ons themselves shouldn't know about Contacts, that's Cardie's job, and they should be created manually by the user (selecting a or several Buddies to compose that Contact).