Closed Bobolx00 closed 1 year ago
If you mean permanent storage, then I think if you're using Chrome it'll grant the site permission to store data permanently after you've used the site several times across a few days, or something like that. Let me know if you're still getting the "not 100% permanent" warning after a week or so.
Forgive me, I did not explain myself well: I read that for the "cross thread" memory i need to open an issue
Ahh, currently there is oc.thread.customData
and message.customData
as you might be aware (added yesterday), but I haven't implemented oc.character.customData
yet. Can you tell me a bit about your use case to help me understand how I can design it?
The main question I need to answer before implementing is whether customData
should get shared along with the share link - just like customCode
does. I think it may be a bad idea to do this because customData
may end up accumulating personal info, depending on what the custom code is using it for.
So if people want to embed custom data along with a character share link then maybe they should just add it to the customCode
as a bunch of JSON.
But the problem with that is that whenever the customCode
is edited, the character's sandboxed iframe is refreshed, and so it's not very convenient if you do actually want to update the character in a way that persists and is shareable.
So perhaps the solution that makes sense is to have oc.character.customData
and also oc.character.customDataPublic
or oc.character.sharedCustomData
, or something like that.
Thoughts?
This is now implemented as oc.character.customData
. Data that should be saved/shared in character share links must be stored under oc.character.customData.PUBLIC
How can I enable character storage?