Arbitrary Object Storage for Addons

Thu, 13 Sep 2018 16:33:23 +0000

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.

Implementation suggestion:
  * add an "attconfig" table (k/v store) and utilities for items in the attach table that mirrors pconfig, iconfig, abconfig, etc. for storage and search of addon-specific attributes.
  * add an "addon" column to the attach table to track the originating addon
  * implement an interface for the content column (insert/update) (attach.os_storage = 0) to store arbitrary data in the database
  * implement an interface for os file contents (attach.os_storage = 1) for addons that may want to allow WebDAV file based updates to app data.

show all 5 Comments

Thu, 13 Sep 2018 21:00:28 +0000 last edited: Thu, 13 Sep 2018 21:16:01 +0000

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!

Einer von Vielen

Fri, 14 Sep 2018 11:23:14 +0000

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

Sat, 15 Sep 2018 16:17:21 +0000

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?