Closed weynandkuijpers closed 9 months ago
challenges / tbd:
to research: benchmark analysis . competitors
Mik had a good point about offering an end-user storage system using QSFS, can we add that in? Probably a bigger lift but we can put it on the roadmap.
Done, embedded in the roadmap.
Excellent!
In the social services section of the table, peertube is there two times. We could remove one. (I can't edit the post so I write it here.)
Another project we could add:
Some ideas and inputs :)
Users of modern cloud services will generally operate under the assumption that data can never be lost. Furthermore, recovering from even a temporary node outage will require that all data can be reconstructed. Restoring a Gitea or Taiga instance with the users configuration but lacking all the stories and code, for example, is a total failure from the perspective of the user.
"Backups" in the cloud context usually refers to the ability to restore some previous state (whoops I deleted all my WordPress posts), rather than an ability to recover from infrastructure failures (whoops my host needed to perform a routine replacement of the single disk my data was solely stored on). Providing users with an opt in backup feature at additional cost seems likely to me to create bad user experiences if (when) they would need the backup.
The only exception I see would be the "developer" focused category, where backups would be a more complicated matter anyway (much easier to identify and target user data in a known application than an arbitrary VM).
More to come, I'm sure, but that's all for now.
Another project we could add:
* provide compute+network to run APIs like the telegram bot and/or AI/ML workloads, like https://www.huggingface.co does
What do you think warrents this a seperate category and does not make it part of "Full VM". Do you consider this to be something that can be replicated for many things (many bots or many API's?).
It might not need a separate category. Good point.
But I was thinking that we could offer a general service where users can try and use different kind of bots and APIs, for specific uses. So, different enterprises would propose different features. The workloads of bots and AI/ML would run on the TF Grid, via Planetary Network when possible, the scripts could be hosted on Github and/or the TF hub.
Users could have the possibility to deploy bots that run on 3nodes. They can write the code on the platform, it gets saved into storage on Github or the TF hub, and the compute of the bots is done by a 3node through the TF Grid.
So for example, a one-click solution to host Telegram bots. You only need to pay X$ per month, the user gives the telegram bot token, and they can run the bot. They can either write the scripts, or simple scripts/bots could be proposed. Also, we note that bots would be using AI/ML in their codes.
The bot's script can be taken from Github or the TF hub, for example, so the 3node runs the script, and if it ever fails, another 3node can simply rerun the script. This is an idea to use mostly the compute capacity, and going over the fact that we can't have "self-healing" compute as we do with QSFS and storage. The compute is centralized on only one 3node at a time. The code is stored and available on Github or TF hub.
On the AI/ML workloads side, it could be done in many ways. For example, we can host standard and mainstream AI for people to use. We can have advanced linguistic translators, text generators, question-answering bots, etc. Each enterprise would focus on one aspect or a group of related features, but all those enterprises could be based on the same basic model, for ease of expansion and development.
This might have some similarities with projects like https://colab.research.google.com/.
How far are we from not solely hosting Wordpress, but offering the standard features of web hosting, like Bluehost does for example?
What we could offer:
As talked with Scott, we could offer some sort of streaming solution, like Plex. If that fits, it could be added on the list. we might need to figure out some details about how we would be doing this.
@xmonader @rkhamis Can we get some feedback on this issue and the comments to understand recommended rollout, what's done & what needs to be done, etc. Then we can create and move on an execution plan.
The meeting was very fruitful and we state here what has been talked in a point-format. This constitutes the basic elements of the project and its parameters.
Create a commercial service provider business
Purpose
To prove that the current state of the TF grid is enough to start a commercial business on. The current TF technology stack is a good set of building blocks to create a service business on. While proving this by doing it we also create content that explains in steps how to use the technical building blocks and put it all together into a full fledged solution.
Outcome
Initial service roadmap:
In the table we're aiming to have only less than 10 initial services to launch with, of which 80% should be already exists today. The focus and effort needed should be around storing the provisioning and customization information backup.
Requirements
Outcome
The outcome for this service provider creation is as follows:
Planning
Architecture
The problem with a FIAT (only) model is how do we create a unique identity and remember / store / create an access method to it. Few options:
Initial though is to create a wallet per individual, have them keep / remember a created mnemonic. Very similar to what we have today for the twitter alternative (mastodon) . That covers the "remember" who you are part, but not the pay in fiat part.
Architecture diagram (DRAFT)