Question and Discussion on Mycelium Project roll out

Hi all,

In an attempt to get all questions, concerns, discussions and (hopefully) solutions in one place, let me give this a head start:

3 ZOS – V4 MOS

  1. We currently have around 70 deployments installed on both our nodes as well as on customer nodes. We have access to it through SLA and need to be able to manage them using our used Terraform scripts and dashboard. We NEED this also in MOS. From day 1.

  2. In the Teraform constructions wireguard is used to connect nodes like Nextcloud to Borgbackup, mycelium is no option. We need to make 100% sure this continues to work after moving.

  3. Our earning model is we buy a lot of tokens, and deploy for customers that pay in FIAT. This construction needs to stay available. Threefold asked for the communoity to beef up usage, we did, now we need to continue this uninterrupted.

  4. We determine VM specs based on requirements for instance Nextcloud. 2 vcpu, 2 GB RAM (default) and 100, 200, 400, 1 TB storage or upon customer specs. We need to continue to have this flexibility regardless of the ‘slice’ system.

  5. We are currently paying interns to write software/LLM for us to be able to deploy on multiple nodes, multiple gateways and backup nodes. Like a clusert with 6 or 7 nodes for instance. Whatever V4 brings, this effort should not be pointless, we invested too much. We continue to need the flexibility on reserving ‘part of’ node capacity based on customer speficications using tokens, not fiat!

V4 INCA – V4 MOS

In 2024/2025 we spend weeks determining specs for INCA nodes. We sold a dozen nodes to customer who invested in the ‘future’. They were promised INCA for a minimum of 18 months, in which they could not deloy on their nodes but receive 100% rewards. They had no visibility on uptime and how many tokens they were entitled to but were told ‘soon’ this would appear somewhere. How are we handling the transition and compensation for these users. And this answer need to come quick!!!

Also…realise that until all the above answers are answered, clarified, agreed and (if needed) solved, it is unfair to use the end of March as a deadline for V4 registration, since there are way too many uncertainties.

Slices:

Why has the slices model been chosen? What is the advantage to the end user/buyer?

Here are some current default node specs:

NUC: 14 vcpu, 64 GB DDR5 RAM and 4 TB SSD storage.
Slices woul become: 8 GB RAM, 1,75 vcpu, 500 SSD.

Rackserver: 88 vcpu, 768 GB RAM, 8 TB storage(and growing)
Slicess would be: 8 GB RAM: 0,92 vcpu, 83 GB SSD.
So, if I need a VM with 4vpcu I’m getting a whopping 32 Gb RAM? And 333 GD storage?

  1. How does the above make sense?
  2. How can customers now choose 100, 200, 500 etc storage? How can anyone ‘sell’ 83 GB storage?
  3. Rackservers are expanded storage based on growth and demand, so what happens to the (current and future) slices of we add another 12 TB to us running 8 TB node?

Nodes:

The minimim specs for nodes are now:
• CPU 6cores
• RAM 16GB
• Storage 1TB SSD
• Network 10Mbps

  1. Why did we switch from vcpu to cpu?
  2. Let me assume it means 6 vcpu/threads;
    Then that node would have 2 slices:
    3 vcpu, 8 GB RAM and 500 GB SSD?

Unless I misunderstand the slices model; to make efficient use of all the different specs and capacity of current (and future…cause their be less cores but more efficient) nodes, should we consider slicing specs up seperately?

12 vcpu means 12 slices of 1 vcpu
64 GD RAM means 64 slices of 1 GB
4 TB storage means 40 slices of 100 GB?

Since the efficiency and speed of cores, the type of RAM (DDR4 DDR5), type of storage? SSD (pci4.0 or 5.0) HDD etc. change over time and all have different pricing, it would also be priced more realisticly.

‘If’ slices are really needed.

Before we invest heavily in brands new rack nodes, we need a rock solid agremeent and understanding of the consequences and ROI.

Sales

We all want the grid to grow and for all efforts to make some return. Whether you’re a farmer or service provider. Usage has always been the keyword here, so, we have worked hard and have dozens of Terrabytes in use on the grid. And MUCH more to come.

What Threefold lacks is understanding of the end users. They seems to believe that building a ‘gadget’ that they would really want themselves, that suddenly eveyone would want that too. That’s not reality. Maybe a handful of nerds do. It takes time, effort, marketing (early in the process, not afterwards)
(Large) companies are the places where most profit can be made. If these can embrace their data running on our grid, it would fly.

Listen to what the market wants!
Now, you can hardly ever run into a medium to large firm and convince them to leave their current service provider alone and switch to the grid. It simply doesn’t happen. Where you need to focus on are the current system integrators of those end users, that have spend years building relationships bring their customer to sharepoint and office365. If THOSE parties wake up and are looking to build pilots with you in order to conviince their customers to switch, that’s where it starts to fly. So, concentrate on these groups that have a lot of buinesses in their IT control or lots of followers like we do. Make sure it is financially interesting for them to take their customers away from 365 to sovereign alternatives.

Nextcloud has taken thast smart path. They now have millions of users world wide and started in 2016. They have dozens of ‘service prividers’ that sell their enterprise seats. Purchase at 19 euro sell at 69.
It is those service providers that now install nextcloud at their clients.

Threefold needs to think about that. USE the parties that have this influence and give them the financial interest to take it furhter. Creating foss for end users will have no attraction for them.

Now, we have more ideas, but will not give them away without being able to make a return.

1 Like

Hi

Thanks for the great post.

So some notes, even if we remove Wireguard as default on node, you can SSH into a node via Mycelium and install Wireguard. This can be done with scripts and should be straightforward. So that is one less thing to worry about.

For the slices, this has been discussed for a long time. But tell me what is the perfect system do you think concerning that?

And yes we are well aware companies and people want alternatives to 365 and such. And Nextcloud are doing very well for sure. One of the reasons we have offered a Nextcloud product for years on the grid now.

What is the ideal way for you to “make a return” on the grid? Let’s see if we can coordinate something.

I would be curious to hear other farmers and providers on the grid.

For the people that got into INCA nodes, we will be able to keep our promise but based on SPORES. We are very grateful to them we won’t let them down. It helped us a lot at that time, and now the new system is built on what we learned in the past.

And the team is working on tools to help workload transition from v3 to Project Mycelium. We just did a test of changing a cluster from one place to another and it worked. So I am confident.

Hi Mik,

Thanks for your reply. On the first subject; we now use terraform scripts that automatically create a WG conf file used for both vm’s on different nodes. In Nextcloud we manually enter the WG ip address as backup location and copy the ssh key into the backup vm. The backups ar emade thourhg WG. Mycelium is not accepted there. So, how can we move all these instances without them being interrupted? And, our current terraform scripts are someitmes still used to up- or downgrade deployments, so, they need to stay connected too. Even more so, I wonder ‘who’ is going to do that since we certainly do not have the time for it. :upside_down_face:

Hi,

Last Tuesday I created and migrated to the Mycelium Project. Today I wanted to login again but then I did not saw my transferred node.
Is it possible that I created a new account without a node? Where is my first account and how do you login to see the migrated node?

Regards,
Erik

Hey guys !

Questions about the slices,

As a user :

  1. If i want to rent storage, will i need to rent X slices until i got the storage i need ?

  2. How will HDD storage be managed?

  3. If i self host a Nextcloud for ex. on my own node and want to make a backup on another will there be an easy way to achieve this ?

  4. If i need a 4 cpu 8gb ram, will i need to rent like 4 slices to have 4 cpu and then getting 32Gb ram ? (if on the server i want to rent, slices = 1 cpu/8Gb RAM)

How custom specs will be managed ?

As a farmer :

  1. What’s the maximal overprovizioning of CPU ?

  2. Does it make sense to have a server with 48vcores / 756Gb RAM to make 96 Slices of 0.5core/8Gb ram ? or should i split these rams between 2 48vcores servers ?

I could also max the vcpu to 88 so it will make 96 Slices of 0.9vcores/8Gb ram.

Typical offers on cloud providers are 2-4 CPU with 4-8Gb Ram, sometimes 16. but in this case, if a user needs 4 CPU, that mean renting 8 Slices, and get 4 CPU / 64 Gb RAM ?

It’s looks like a waste of ram, and useless expense for the user.

I think the ratio of 8 Gb RAM per slices is too high, and/or the possibility to rent custom specs slices is needed.

Also for the Baseline rewards, with actual system of slices, on slice is not egal to on slice, 0.5Core/8Gb Ram is not equal to 3vcpu/ 8 Gb ram (as mentionned by Robert) I’m not sure how fair this can be.

What do you guys think ?

Hello there,

If you initially used your Mnemonic Phrase (24 words) to link your farm, and that didn’t work, please use your HexSeed (also called TFChain Secret) from the TFConnect App.

Open the ThreeFold Connect app and navigate to Farming, then switch to the V3 tab and select your farm. From there, you can view, and copy your TFChain Secret.

For additional assistance, please connect with our support team.

Hi,
Thanks, that did the trick.
Regards,
Erik

1 Like