Enable GitHub storage

[Keyrxng]

We can make global storage private

I'll just disable the GitHub storage layer for now and continue to use Supabase.

I'll address Global Storage as a separate issue and refactor later.

#3 Implements all of the required logic for using GitHub as a storage layer but #12 is a blocker for implementing it safely right now. There is no task for global storage yet but creating this as a reminder/milestone so I can push #3 forward and then link this to the global storage task as part of it's QA that this feature works effectively.

original context

[rndquu]

By "github storage" we mean saving data to json file in partner's .ubiquity-os repository, in particular in a storage branch. As far as I understand right now this feature is disabled.

Questions:

1. Here the term "global storage" is used. What's the difference between partner's github json storage in a repository and a "global storage"?
2. Perhaps we should move current github issue directly to https://github.com/ubiquity-os/sdk (not sure why the repo was removed)?

[Keyrxng]

By "github storage" we mean saving data to json file in partner's .ubiquity-os repository, in particular in a storage branch.

Yes 0x4007 has stated that's the direction he sees for it.

1. Not sure of the vision exactly but right now storage is bound to the partner' config repo. Global storage as far as I understand it will be a single centralized storage repo that we control as opposed to the partner.
2. This issue in particular is for enabling it within just this plugin. I've assumed this would be the pilot and we'd refine the logic from here and then embed it into the SDK once it's stable and stress-tested a bit

---

I think GitHub storage should be like this:

• private storage repo per partner; can consolidate into a single repo across orgs if a partner has multiple (as we do)
• private because sensitive data will be stored from more than just this plugin or we'll need to encrypt/decrypt, another gotcha in plugin development. GitHub storage should be like any other solution, private and have some access control.
• consolidate into a single location so that in the eyes of the partner, they have global storage.
• plugins are building isolated datasets which are better as one
• e.g plugin A needs the ubiquity userbase but is ran inside ubiquity-os-marketplace which is new and so has no recorded usage of /wallet yet
• e.g a contributor must call /wallet in all four of our orgs to register their wallet

I don't see any pros in making the GitHub storage location public. I see the pros in using the .ubiquity-os repo but if that's going to be public now that introduces a problem.

[rndquu]

@Keyrxng Can we close it as "not planned" in favor of ubiquity-os/plugin-sdk#30?

[Keyrxng]

Idk mate

Who is working on what? What has been delegated etc?

Yeah the GH storage module should be within the SDK but we were talking about QA-ing the GH storage layer and stress testing it within a plugin. So does it make sense to do it in the sdk first? idk.

[0x4007]

Who is working on what? What has been delegated etc?

Although there is a high level plan with some names associated, the only official "delegation" occurs in visible conversations under those tasks on GitHub either via tags or direct assignments.

If they aren't being worked on in a visible form on GitHub we can consider these to be open and available.

So does it make sense to do it in the sdk first? idk.

I think it's considered more proper to implement it there, and then implement the updated SDK here.

[Keyrxng]

Can't view the link because its a private repo

Who is working on what? What has been delegated etc?

Although there is a high level plan with some names associated, the only official "delegation" occurs in visible conversations under those tasks on GitHub either via tags or direct assignments.

If they aren't being worked on in a visible form on GitHub we can consider these to be open and available.

I can't see the org readmes but they clearly delegated specific tasks and features to core team members but klkl no worries

I think it's considered more proper to implement it there, and then implement the updated SDK here.

So ubiquity-os/plugin-sdk#30 should be cleared and merged first then no?