Skip to main content


Newmonic™ would be a software product to help people save information to be securely and easily accessible through any Internet connected device. Newmonic™ also aims to help people save information more quickly, more safely, and in larger quantities.

The customer would only need to setup the app, and then they would be able to use Newmonic™ on their device the same way they would use traditional storage--except there would be more of it and it would be faster and more secure.

Observations: There is a trend of increasing interest in accessing the same information at different locations and through different devices. Also, the need for faster, more secure, and larger quantities of persistence seems like it will continue to grow indefinitely.  There is already a definite trend to use RAM in large quantities as a substitute for persistent storage. RAM is much faster than persistent storage. Strong enough encryption is available to keep data as secure in the cloud practically as if it were on separate private devices.

How it Could Work: Newmonic™ would accomplish its goals through RAMCloud (as others have also proposed) and DRY-FS™ (Don't Repeat Yourself File System). It would replace local persistent storage (hard disk drives, solid state drives, etc.), so the information would never be stored on such a device.

RAMCloud would provide a virtual persistent storage device through RAM in the cloud (possibly in secure data centers). Information would be replicated across nodes to ensure reliability. Perhaps those nodes could be geographically disparate. Although one node may go down here or another node may go down there, it is reasonable to expect there could always be a node up somewhere with power running on the Internet. (It is very unlikely that significant portions of the Internet would be disrupted for extended periods of time, except for in what would already be extremely catastrophic events.) This would basically provide a distributed RAM disk, and thereby ultimately enable virtual persistence.

DRY-FS™ is based on the observation that most of the information people persist is redundant, or small variations on larger collections that are mostly redundant. Sure, each person needs to be able to store some of their own information that is truly unique to them. But, for example, how many people had a copy of Windows 10 on their hard drive, or the latest version of Microsoft Office? Does each person really need their own copy of all of that information? 

DRY-FS™ could store data in a way that is somewhat similar to version control--in that it would store a single copy of commonly reused data, and store the variations on that data separately. In that way, it might also be thought of as somewhat similar to universal compression.

Finally, DRY-FS™ would turn access control inside there would no longer be multiple copies of data on various devices, to which each person had their own local access. Rather, DRY-FS™ would use an overall access control system in which local devices would be irrelevant and strong encryption would be used to ensure the right users could access the right data.


  • Security: Since the information would be distributed instead of contained on private local devices, we would need to employ strong encryption and access control to ensure security. The technology is probably already to the point now where using adequate encryption is more secure than using a private local device
  • Performance: Using encryption, compression, and communicating over the Internet with limited bandwidth would cause concerns with performance. The fact that we are moving information from drives into RAM should boost performance greatly. We still need to figure out what to do about the fact that local storage can be faster than networks; perhaps a broader cloud solution where data is processed on processors closer to the storage rather than close to the user
  • Capacity: Since RAM is much more expensive than hard disk drives, we could have challenges moving all of the information usually stored on drives, into RAM. This would be more of a problem as the data needed to be redundant for virtual persistence. DRY-FS™ could help with these problems.
    • Also, perhaps would could use something like a system that would share idle RAM across devices. For example, if I have 1.5 of 2 GB used and you have 1.5 of 2 GB used, neither of us have space for something that takes another 1 GB, but if we share we have 3 GB of 4 GB used, and we do have enough space to store something that takes another 1 GB

Verified Author: Serafino Software™
Maturity Idea 
Type: Software Product
Date Claimed: 1 September 2017


Popular posts from this blog

Shared Project Manifesto Version 2

Contents:IntroductionLaunchTradeRewardDevelopVoteHarvest 1. Introduction IP (Intellectual Property) is a great asset but it is hard to produce well. We hypothesize that a market to facilitate shared projects would make it easy to produce IP better.

The market contains projects. Each project has one admin and a number of traders and developers. One user can have any combination of roles at the same time. For example, a user may be an admin and also a trader, or a trader and also a developer. ProjectsUsersAdmin: Provides ideas in exchange for controlTraders: Provide incentives in exchange for growthDevelopers: Provide IP in exchange for incentives 2. Launch When somebody came up with an idea for an IP product, they could create a project for it on the market. That person would be the admin.
The market would record the time the admin launched the project. That lasting record could provide for the admin to claim credit for the project idea, on a first-come, first-served basis. This recogn…

Contact Codes Lite™

CCL (Contact Codes Lite™) would be a software product to help people exchange many kinds of contact information much more easily. CCL would do this by providing users with relatively simple contact codes. The users could distribute the codes to many people in many ways. Then, a person who received a contact code could use it to retrieve the original person's contact information through CCL.

For example, many people still exchange business cards. Retrieving various information from the cards can be time consuming and error prone, especially when there are many cards. Also, when somebody updates their information, the information from the card is no longer valid.

Other good examples for usage of contact codes include:
On a slide in a presentationIn email signaturesOn name tagsIn applications that provide limited space for profile informationWhenever you want to provide easy access to many different contact options without listing each
The main thing that would make CCL different from…

Fog Machine

Fog Machine™ (named because fog is like a cloud, on the ground) is a software product to provide cloud services to customers without a cloud service provider. The problem with the traditional cloud is that it requires a provider. Fog Machine™ would run cloud "nodes" in idle system resources on ordinary user's devices. This would be a peer to peer system in which each connected device would be a peer.

It would support standard cloud APIs (perhaps Cloud Foundry?) and it would be easy to port cloud apps to it off providers such as Google cloud, Azure, or AWS--or maybe it would be effortless for apps that were already portable through compliance with open standards.

We might use encryption for privacy, redundancy for reliability, and remuneration/incentive for resource consistency. The showstopper (critical assumption) is that the synergy would be sufficient to significantly surpass the overhead, and provide competitive performance for at least some types of cloud applicat…

Please Comment

Have you ever heard of a similar idea? What challenges might an idea run into? How might you like to be involved? Comment to add your voice to each idea.