...

collections/problems/content_providers.md

@@ -0,0 +1,42 @@
+# Solution for Content or Social Network Providers
+
+Content providers have quite some issues in supporting their user base, our approach can help.
+
+Below you can find how we can help you to resolve some of your possible issues.
+
+## lower your CDN cost = Content Delivery
+
+- costs typically are +50 USD per TB, our solution goes below 10 USD.
+- cost goes to 10 USD at start, from v2.0 can be even lower.
+ 
+## Lower your cost of operations
+
+- ThreeFold has developed a self healing capable system which lowers your cost of operation dramatically.
+
+## Avoid any control or interference from others
+
+- Our clouds are unbreakable and cannot be shutdown or interfered with.
+
+## Get more scale
+
+- There are no limits to how far you can scale your app.
+
+## Sideload your mobile apps
+
+Vendors like Apple have a lot to say on how you deploy your app, we can work around that:
+
+- one app will be called TFConnect and will be the app running the peer2peer network Mycelium, identity management, reputation management, reliable message bus, geo dns, content caching,... TFConnect will be available for all major desktop and mobile platforms.
+- Then there will be multiple apps which can be native and web, the apps will talk to TFConnect on the device or desktop.
+- We suggest to also develop a rich web app which connects on the Phone to TFConnect, this cannot be blocked and would be ideal fall back solution in case the native mobile app gets blocked. Current web technology can be made in such a way it would act almost the same compared to native, thanks to TFConnect it would still be fast and highly responsive.
+
+## Integrated solution for GDPR
+
+- By design resolved in 2.0, all data is owned by the user.
+
+## Redundancy / Uptime
+
+- Its possible to achieve 100% redundant and should never be able to go down.
+
+
+
+

collections/problems/internet_infra/cdn_issues.md

@@ -7,3 +7,47 @@
 - Managing these CDN's is expensive and not easy job.
 
 >> this means to service 10m people it would cost about 1 to 2m USD per month just for CDN alone.
+
+
+# CDN pricing Amazon
+
+Remark no fees included for HTTPS requests, but should be ok for volume we are talking about, if app is made in right way.
+
+## US
+
+![](img/amz_us.png)
+
+= 28 USD per TB in US
+
+## EUR
+
+![](img/amz_eur.png)
+
+## MIDDLE EAST
+
+![](img/amz_middleeast.png)
+
+= 56 USD per TB
+
+## AFRICA
+
+![](img/amz_sa.png)
+
+= 56 USD per TB
+
+## Discounts
+
+- discounts can be negotiated but required serious amounts of pre-financing
+
+# CDN pricing Google
+
+Remark no fees included for HTTPS requests, but should be ok for volume we are talking about, if app is made in right way.
+
+![](img/google_1.png)
+
+![](img/google2.png)
+
+https://cloud.google.com/cdn/pricing
+
+
+

collections/problems/internet_infra/cdn_pricing_amazon.md

@@ -1,32 +0,0 @@
-# CDN pricing Amazon
-
-Remark no fees included for HTTPS requests, but should be ok for volume we are talking about, if app is made in right way.
-
-## US
-
-![](img/amz_us.png)
-
-= 28 USD per TB in US
-
-## EUR
-
-![](img/amz_eur.png)
-
-## MIDDLE EAST
-
-![](img/amz_middleeast.png)
-
-= 56 USD per TB
-
-## AFRICA
-
-![](img/amz_sa.png)
-
-= 56 USD per TB
-
-## Discounts
-
-- discounts can be negotiated but required serious amounts of pre-financing
-
-
-

collections/problems/internet_infra/cdn_pricing_google.md

@@ -1,10 +0,0 @@
-# CDN pricing Google
-
-Remark no fees included for HTTPS requests, but should be ok for volume we are talking about, if app is made in right way.
-
-![](img/google_1.png)
-
-![](img/google2.png)
-
-https://cloud.google.com/cdn/pricing
-

collections/problems/internet_infra/cloud_issues.md

@@ -1,4 +1,6 @@
+# DO current centralized clouds resolve your problems?
 
+This page describe some of the issues you might encounter if your use clouds to fullfil your requirements for your solution.
 
 ## high CDN cost = Content Delivery
 

collections/problems/painkiller/no_pain_killer.md

@@ -2,9 +2,11 @@
 
 ![](img/painkillers.png)  
 
-Currently, most countries develop their digital future by implementing many independent projects which all act as painkillers to their problems. While a painkiller might fix symptoms, it rarely solves the root issue.
+Currently, most develop their digital future by implementing many independent projects which all act as painkillers to their problems. While a painkiller might fix symptoms, it rarely solves the root issue. This happens for content providers, countries, enterprises.
 
-We believe your country has the opportunity to leapfrog straight to a solution which is both easier to implement and solves most of its issues all at once.
+We should stop treating the symptoms it becomes time to resolve the root cause.
+
+We believe you have the opportunity to leapfrog straight to a solution which is both easier to implement and solves most of its issues all at once.
 
 This has huge benefits:
 
@@ -14,3 +16,27 @@ This has huge benefits:
 * It is more prepared for the future
 * It's greener (such a system will use up to 100 times less energy)
 
+## onion layers
+
+![](img/onion_layers.png)  
+
+What has IT to do with onions...
+
+The development of applications in the IT sphere has been using painkiller methods at each layer of model first patterns to go forward. 
+
+## Model First Pattern
+
+![](img/model.png)
+
+A model first pattern has a standardised foundation. When there is a problem or a bug, or when changes are required, it is not possble to change the sublayers, so a new layer is created. Making changes in the middle is affecting everyhting else that is on top, therefore, it requires more work. Layers keep being added on top of the base which adds complexity, si the problem is never fixed at the root. 
+
+The model can be seen as a dictionary that keeps on expanding more and more. 
+- More but complex words = Harder to understand
+- Less but simple words = Easy to understand
+
+Now, imagine when hundreds of such models are connectted to one another and exchanging information. The more layers each indivdual model has, the heavier it is for its message to get across. The whole system becomes very complex. 
+
+The problem here is that individual systems are trying to redo things better, however they are using the same base infrastructure. They simply redefine that base towards a relevant issue. Ths cannot lead to optimal systems since solutions are managed around a single functiion. If multiiple people need to use that function it gets very complicated. 
+
+One way to go around this has been to use Enterprise Message Bus: Controlling how models talk to each other by pre-defining the messages exchanged. But this does not solve the problem at the root.
+

collections/problems/painkiller/onion_layers.md

@@ -1,25 +0,0 @@
-# onion layers
-
-![](img/onion_layers.png)  
-
-What has IT to do with onions...
-
-The development of applications in the IT sphere has been using painkiller methods at each layer of model first patterns to go forward. 
-
-## Model First Pattern
-
-![](img/model.png)
-
-A model first pattern has a standardised foundation. When there is a problem or a bug, or when changes are required, it is not possble to change the sublayers, so a new layer is created. Making changes in the middle is affecting everyhting else that is on top, therefore, it requires more work. Layers keep being added on top of the base which adds complexity, si the problem is never fixed at the root. 
-
-The model can be seen as a dictionary that keeps on expanding more and more. 
-- More but complex words = Harder to understand
-- Less but simple words = Easy to understand
-
-Now, imagine when hundreds of such models are connectted to one another and exchanging information. The more layers each indivdual model has, the heavier it is for its message to get across. The whole system becomes very complex. 
-
-The problem here is that individual systems are trying to redo things better, however they are using the same base infrastructure. They simply redefine that base towards a relevant issue. Ths cannot lead to optimal systems since solutions are managed around a single functiion. If multiiple people need to use that function it gets very complicated. 
-
-One way to go around this has been to use Enterprise Message Bus: Controlling how models talk to each other by pre-defining the messages exchanged. But this does not solve the problem at the root.
-
-

collections/problems/resolve_a_problem.md

@@ -1,2 +0,0 @@
-# What do we resolve
-