Feature request - Ability to store custom vars for a friend in the .tox file

[SkyzohKey]

Hey guys,
I just had an idea that it would be nice to be able to store custom variables in the .tox files for a friend (ie. alias, custom avatar path, is_blocked, etc). I mean, using the Tox API we (the clients devs) would be able to define global custom vars that would be shared between clients only using the .tox file. That would also permit to have less databases for per-friend settings which would improve clients weight.

Also, a client can choose to store nothing in the friend custom vars or to ignore the custom vars setted for this friend.

Hope this will be discussed in order to make Tox even better ;)

[ProMcTagonist]

Sounds nice.

[GrayHatter]

👎 this seems to be a duplicate of https://github.com/Tox/Tox-Client-Standard

not to mention, it's an API that's just asking to be used as an attack vector.

There are arguments to be made for a friend alias, but I'm not convinced about anything else...

[ProMcTagonist]

this seems to be a duplicate of https://github.com/Tox/Tox-Client-Standard

It is definitively not that and is in fact of quite the opposite intention, since that repo is for regulating behavior that is not enforced by core, and this issue is about adding a feature to core.

not to mention, it's an API that's just asking to be used as an attack vector.

1. How?
2. Moreso than anything else Tox already does?
3. Encrypt your profile.

[GrayHatter]

It is definitively not that and is in fact of quite the opposite intention, since that repo is for regulating behavior that is not enforced by core, and this issue is about adding a feature to core.

I meant more that; sharing info to allow clients to be compatible with each other seems like it shouldn't be a core issue/feature.

Right now (unless I'm mistaken.) Most of what's saved in toxcore saves is fixed length. some of these would need to be variable length, some are just asking for trouble, e.g. avatar paths. But even without those, the more space you make available, the larger the shellcode opportunities.

What about a malicious client using toxcore saves to mess with other clients?

[SkyzohKey]

Sorry if I badly explained this. What I suggested is to be able to store custom values in a .tox file. This would permit for clients devs to avoid the need to add extra dependencies (such as database or .ini reader) and have a better clients cohesion. This would permit to store useful informations about a friend and have it usable by any client. Like mentioned above clients would have to check only the variable they want to use and ignore the other ones.

[Renha]

Hi Key. Looks like it would be too complicated to be inside of core. Personally I want to have such possibilities too, but I think core is already overcomplicated, so we must be very careful when we deals with adding complicate things.

[ProMcTagonist]

We could try and avoid these issues by defining a standard external config format... but then we're practically in STS territory, outside the core save.

[TheNain38]

I think that instead of adding custom vars, it would be better to add a bit to indicate if a contact is blocked, and something about the alias. It would be better to have this in core, than adding custom vars...

[SkyzohKey]

Hey.
It would be nice to have a bit for "is_contact_blocked", " alias", etc. This is clearly the goal of this issue ;)

[alexbakker]

The ideal solution, in my opinion, would be to move save file formatting out of the core entirely and let the clients take care of it. This format would have to be standardized in the TCS, probably.

For example, if we decide to use xml or json, clients could add their own custom vars without issues or interfering with each other.

[TheNain38]

I think json would be more appropriate as it's less verbose than xml... and easy to modify by hands

[LuccoJ]

At the same time, I see some value for end users in only have one .tox file to move around to carry "everything contact-related" over, instead of a .tox file plus one or several non-core files...

[ProMcTagonist]

The ideal solution, in my opinion, would be to move save file formatting out of the core entirely and let the clients take care of it. This format would have to be standardized in the TCS, probably.
json
xml

Please no.

If you're willing to do that, it's faster just to standardize on an external config with the variables @SkyzohKey is talking about.

[Renha]

It would be nice to have a bit for "is_contact_blocked", " alias", etc.

Today we want this, tomorrow new groupchats will arrive and we would want per-group "mute" bit, for example.

So we should either make savefile less solid (by adding variable length and count, named fields) or don't touch it at all.

There are no browsers that uses same profile, or bookmarks, or cookies files. Even different versions of same browser don't use same files - and they have a reason. I agree that for Tox sharing savefile is only way to share profile and a contactlist, and it works for now. But it works because savefile is relatively simple.

Another thing that browsers share are webpages - and look at the pages code! There are so many moz-border, webkit-border, etc. Awful. Do you want something like that for Tox? I'm not. So please use client-specific files for such settings or standartize it for cross-client usage.

Partial solution could be archiving profile.tox file and ricin.settings file into [profilename].toxz (for example) and standartize that filenames. Wow, i love that solution!

[TheNain38]

I love the last one @Renha talked about ^^ So, settings would be in the archive and .tox too, and you could always import it in another client, he would just ignore other files than the .tox and his settings file for him. +1

[aaannndddyyy]

For the user ideal would be only one file to be moved around, containing as much of his settings as possible, that means list of ignores, maybe even avatars he is using, nick-name overrides aka alias, maybe even the theme you are using - ideally one standardized file for each. The file should nonetheless remain small.
If one client does not support a certain feature or does not understand the format of the respective file, it ignores it and falls back to its defaults.
Problem would be with conflicting standards. One client saves info in standard A, the other client also supports the feature yet uses a different standard B (maybe just a wrongly implemented version of A) and now saves its settings in that file but using standard B.
But as you don't permanently move your profile between two clients, I don't think it is a big issue.
Also, clients should not write to the files in only defaults are used. Rather only write if the user did an actual change.

[SkyzohKey]

The JSON format would be a nice solution to store settings, ie. like @Renha mentioned we could have a .tox archive that would contains .json files for friends, avatars (base64 encoded ?), global settings, etc. The client settings should still stay in a different file that wouldn't be into the .tox archive. It would let the Tox file be more modular and avoid the need to update the ToxCore for minor updates like that.

[aaannndddyyy]

Yes, that was proposed already, and it seems to be the most reasonable solution.
It would be only one file the user has to copy/backup and yet it would keep the .tox file untouched.

[Renha]

I think we should leave .tox file as it is, to be only one necessary for work. Just place it into archive for clients to be able add their custom datafiles. Because we even don't need to update toxcore to do that, if client would unzip .tox file.

We even could work with non-archived .tox files, just by checking if profile has .tox or .toxz extention.

The client settings should still stay in a different file that wouldn't be into the .tox archive. It would let the Tox file be more modular and avoid the need to update the ToxCore for minor updates like that.

I don't quite agree. Tox core should care only about (unarchived) .tox file, all other things are client's work. That way we would avoid the need to update the ToxCore for minor updates like that, will be very modular, without user's need to deal with tons of files to backup/sync.

[GrayHatter]

Don't forget, any change will require both legacy support, and will require
all clients to update handleing.

You'd have a lot on convincing that what you're suggesting is the best way
to do this.
On Jan 19, 2016 23:41, "Renha" notifications@github.com wrote:

I think we should leave .tox file as it is, to be only one necessary for
work. Just place it into archive for clients to be able add their custom
datafiles. Because we even don't need to update toxcore to do that, if
client would unzip .tox file.

We even could work with non-archived .tox files, just by checking if
profile has .tox or .toxz extention.

The client settings should still stay in a different file that wouldn't be
into the .tox archive. It would let the Tox file be more modular and avoid
the need to update the ToxCore for minor updates like that.

I don't quite agree. Tox core should care only about (unarchived) .tox
file, all other things are client's work. That way we would avoid the need
to update the ToxCore for minor updates like that, will be very modular,
without user's need to deal with tons of files to backup/sync.

—
Reply to this email directly or view it on GitHub
#1487 (comment)
.

[ProMcTagonist]

we'd better hurry and break things now then

[Renha]

working with .tox as usual (client configs in same dir)
working with .toxz new way (imagine that .toxz IS a dir i've talked line earlier)

I can't see any breaking here.

[ProMcTagonist]

@Renha wrap it and ship it

[aaannndddyyy]

Any news re this?