Who can see your viewing activity?
This is so exciting
This is very big - so with no need for a context switch, what are we expecting in terms of performance?
Especially if we go from 8GB to 32GB to 300GB
Let's say I have a BTree data structure, does the read/write performance stay at log(n) as I scale out to the whole subnet?
I assume it would be n * logn, n being the increase?
And the optimizations would reduce n?
Oh c * logn?
c = overhead
c + logn
So you're thinking about like a stable schema? Or one that allows for migrations
What does this mean for Motoko, since so much of the current development patterns there are based around heap memory?
I think a straw man example for a key-value store would be a good starting point to help people understand how it might work
This would make heap memory only a specialized use case if stable memory is really able to perform at this level
Is there any difference in the hardware used in heap memory vs. stable memory?
annoyingly I need to drop off for another meeting 🙁
What’s an optimistic and conservative timeline on 32GB stable memory, multiple memories backing stable memory, etc.
So you have an auth service that generates auth tokens with a ttl that the frontend can use to communicate with your other canisters? How do the other canisters verify the authZ token is valid?
It’s based on a HMACed token. So secure against tampering by clients, but boundary nodes/replicas could learn the secret
Meidhy what are you working on?
creating a pool and assigning new ones from the pool?
Yea, I think this is the canister pool idea
The stable storage abstraction still has the issue that you share your “canister” with every other project in that subnet, so 32GB and 300GB is all relative to the subnet you're using, right?
Inter-canister/subnet calls are expensive and slow, I wonder if that needs to be greatly improved for the IC to reach its potential. Seems like a fundamental breakthrough in consensus might be necessary here
There's definitely a tug-of-war when designing your application to build a monolith, or a shallow architecture with multiple canister microservices and all calls being shallow from the frontend client (no inter-canister calls). I'm assuming this bump up in stable storage will shift much of the main application back to a single canister
Quick inter-canister calls will push back to microservices, would also help with the authZ token issue by providing a different pattern
Johan Georg Granström
I think inter canister calls _intra subnetwork_ can be substantially optimised, but not _inter subnetwork_. So, with optimised _intra subnetwork_ canister calls and larger stable memory, the subnetwork is the clear scalability boundary - beyond which a shallow architecture is most appealing.
How will subnet splitting affect the stable memory changes
Or work with that
Jesse - Portal
Yes, when subnet splitting?
I see, so subnet splitting would affect a multi-canister architecture
But not a single canister
Jesse - Portal
Are there any known solutions for scaling across subnets when they fill up?
Thanks for the updates, very exciting
Thanks guys !