last edited: Sat, 15 Sep 2018 12:25:57 -0400  
The goals:
* Maintain current security regarding content restrictions and content filtering in existing apps/modules.
* Maintain/allow privacy settings and restrictions on stored items of existing modules/apps.
* Allow addon devs to store and retrieve arbitrary unfiltered data for use by their addon.
* Allow arbitrary unfiltered data to be assigned privacy settings and restrictions consistent with other modules/apps.
* Provide a mechanism for unfiltered addon data to be cloned to channel clones. (Nomadic identity remains in tact even if the addon is not installed and running on the clone's hub - the data will not be used without the addon (unless it's accessible through the cloud/file interface), but it will exist in the even that the addon is installed and activated in the future).

Proposed solution:
* A standardized interface for addons to track/access and save and retrieve data in the existing attachment file store as an arbitrary data store.

NEW Implementation suggestion: (Updated 9/15/2018)
* Store file metadata in pconfig with a structured category appfile:{appslug}:{filehash}
* Create an interface to interact with the existing file storage functions - or - possibly even leave it to addon devs to interact with the storage functions as it shouldn't really be that complicated at that point.
  last edited: Thu, 13 Sep 2018 17:16:01 -0400  
From my remberance of the code, both item and item_id are cloned, you are correct.

No apology needed for talking about your project... It's great to hear how others are using the platform! It's good for ideas and it's good for the devs to know others are making use of what they have created!
  
It's good for ideas and it's good for the devs to know others are making use of what they have created!
I do not much comment usually but read the dev and support forum like a newspaper every day. It is very interesting to follow the thoughts. It helps me to understand better whats going on under the hood of Hubzilla
  
Investigating and thinking through implementation....

I'd rather not muck around with the core. Creating AttConfig appears it will be a nightmare - and I don't think sending whole file updates with every meta data change is reasonable. Now I'm thinking of a completely different implementation - but with the same result - feedback would be appreciated.

Instead of using a new "config" table for meta data and needing to build a new synchronization structure, what about using the current pconfig to store file metadata for the files?

I'm thinking: structure the 'category' something like appfile:{appslug}:{attachmenthash}. Then the app can have full control over the 'key' and 'value'. This has the benefit that PCONFIG is already nomadic aware. And updates to meta data will not trigger the added network traffic of a file synchronization.

The only complication I can see is the possibility of file deletion while leaving meta data. But I think a hook in the attach_delete() function could easily remedy that.

This means no core coding (except for the additional hook), and should still permit an implementation of the intention of arbitrary object/file storage for apps.

Thoughts?