Facebook PixelA long term reminder service that executes after decades
Brainstorming
Brainstorming
Create newCreate new
EverythingEverything
Sessions onlySessions only
Ideas onlyIdeas only
Idea

A long term reminder service that executes after decades

Image credit: troler / ebay

Loading...
Darko Savic
Darko Savic Aug 06, 2021
A reminder service that reliably delivers your message after decades.

I converted this from a brainstorming session to an idea because I think I have it figured out now.

Problem

How can people set reminders to go off in 30-50 years? We can assume that there will be all sorts of new technology by then. All of our devices will likely be replaced. The world will be a different place.

Then there is the fact that people move around, even to different countries, change phone numbers and emails. Some people change identities. Old social media accounts become obsolete. I imagine that not many people remain reachable at the same address for 30-50 years.

Solutions

Technology

Even when the technology changes, old tech doesn't stop working. All the records would be kept:
  1. What ever technology is the most suitable for this at the time. Salemandreus listed a few current options in the contribution below.
  2. An internal blockchain, run from multiple nodes in multiple locations for redundancy. The reminders are handled by smart contracts.
  3. Analog paper form. Something resembling the old style library card system. Dual copies of this would be kept at different locations.
Required data

A person wanting to set a long term reminder would have to provide a bunch of data including the identities, addresses, contacts of children, relatives, friends, employers, etc. This could be useful in a few decades when trying to locate the recipient.

Open source auditing

This makes the service reliable.

When someone sets a new reminder on the service, they have to agree that anyone in the future has the right to start an auditing process to verify if a reminder was actually delivered. To protect people's privacy the person that initiates the auditing process doesn't actually get to see any vital info, but the law firm of their choice does. Here comes the kicker - whoever starts the auditing process pays for it. However if the reminder service is found not to have delivered the message (out of negligence or the lack of effort) then it pays for the auditing in addition to a hefty penalty/reward to the person who initiated the auditing.

The goal with this is to have "reward hunters" going after the reminder service to find any negligence or lack of effort.

Finders budget

When a person sets a reminder in the service, they get to set the budget that pays for the service's efforts in locating the recipient to deliver the message to. The higher the budget the higher the chances that it will be enough to locate someone. Ideally the service would work with several highly resourceful individuals that are skilled at locating people. Private detectives, bounty hunters, retired police detectives, etc.

Even without the finders budget a good amount of effort will be put into locating the recipient. The lower the finders budget, the lower the penalty if auditing found the service didn't try very hard.

Business model

The business model of such a service would be very similar to an insurance company.

Delivery of goods

The service could be extended to deliver memorabilia, goods, letters, valuables, etc. at a future date. That would require leasing secure vault storage and additional safety and auditing mechanisms to prevent theft, etc.

Survival of the reminder service

The reminder service firm could theoretically be sued/penalized out of existence if it fails to deliver enough messages. There should be a safety mechanism that ensures all the pending messages get delivered even if the firm has to shut down.

This could be solved by creating a non-profit daughter firm that controls just enough funds to get this done. I imagine there would be just a handful of employees there that have the characteristics of Forest Gump or the main character in the movie Cast Away. They would get the job done regardless what happens with the world around them.
1
Creative contributions

Multi-instanced, idempotent, heartbeat- and service-monitored, perpetually-running script on cloud services using future-proofed universal formats for easy and supported data exporting and conversion

Loading...
salemandreus
salemandreus Aug 10, 2021
A real-life example of this and how to sustain it
At a Burn event, I actually met someone who does exactly this.
In his case it's in the form of recording a video message from the person themselves, to be sent to themselves or some other email address at some point in the future. I recorded my own video to be emailed to someone in 5 years' time and CCed to me so I know when to follow up when they're supposed to get it.
The sending is powered by a script he wrote, which runs continuously as a service on AWS-hosted cloud services and checks periodically whether it's time to send- it is possible to get really cheap or even free compute power and long term storage on their platform as AWS and other cloud providers also provide these environments for as people often want to test their services first or test their code on a free scaled-down environment before they consider deploying it live to a customer audience.
In this case, you would be handling smaller amounts of data and not the scale of requests of larger services so it would fit into that bracket of lower demand for storage space and would likely also be inexpensive unless it grows to the size of something like a Google service, as people would not be leaving as many messages for themselves in the far future as they would for, say, reminders in a calendar app over the next month.
But the use of cloud services, aside from optimizing the costs at which it’s available also makes it easy to flexibly scale up and down as demand dictates.

Data loss prevention
Large cloud service providers like AWS, Google, Azure etc also provide extra prevention against data loss through being able to utilize redundant storage across multiple servers, in case of potential damage to the storage hardware. They even have geo-redundant storage, so you can ensure your data duplicates are stored in geographic locations which are far apart from each other even on different continents, so that in the case of a natural disaster taking down an entire data centre your data would still be safe.
Geo-redundancy would be particularly relevant when considering you would be needing long-term storage (particularly with the increasing dangers of extreme weather due to climate change).

Monitoring Uptime
In terms of the service itself, the person hosting the service could get notified if their script stops running and anything goes wrong on AWS it would also notify them, so you would likely not have to manually check on it.
AWS also would have analytics for checking for any failures of requests, failed sends and tracking other errors.
If you wanted an extra failsafe for the running for the script itself it'd be easy to write a "heartbeat" script (I’ve done it before as a means of monitoring a service’s SLA uptime) that checks as frequently as you like if your this service is still running and notifies you if it stops responding.
In the case of something failing it'd be easy to have a batch send mechanism with this early alert where, if the service stopped running for some reason, it would consult the latest successfully sent entry times and trigger the remaining notifications to be sent as a batch.

Another way to ensure that the sending definitely goes through would be to have every send trigger more than once, or reattempt multiple times, but idempotently, meaning that while the request to send can go through multiple times, only one successful send will be allowed (meaning the person will not get spammed with multiple emails). This checking should cut down on potential failures due to network errors meaning there would be less likely to be cause for alert if the service was down only briefly. The heartbeat script itself or a service triggered by it could restart the service if it does not respond.

You could have geo-redundancy for the heartbeat service as well, and more than one instance of both that and the main service running as well, still idempotently, this way not only is your service unlikely to go down due to there being more than one instance of it running, it would itself be monitored by multiple heartbeats as well as the cloud service provider's own monitoring services.

Compatibility for future-proofing data porting
Making the actual data easily exportable to another platform if it is stored as an iCal for example for calendar compatibility, or in XML/JSON/YML/CSV file for general compatibility would help with future-proofing because even if you migrate to another system, the record of all your saved future dates is there in a widely supported format so even if those for types get deprecated in future there are already many easy ways to convert them and many platforms supporting them so that'd be a quick and easy data format conversion, especially as the latter file types are specifically designed to be universally acceptable formats.
With this portability of data via an easily accessible universal format, you wouldn’t have to worry about whether their current tools and apps will still be working in the future, you’d be able to upgrade your script to newer technology and hardware as frequently (and possibly as infrequently) as you like!
Loading...
Darko Savic
Darko Savic2 months ago
All good solutions. You could also store the important data on the blockchain and run a few nodes for redundancy. Reminders could be handled by smart contracts. They execute several pre-reminders when the due date begins to approach.

Add your creative contribution

0 / 200

Added via the text editor

Sign up or

or

Guest sign up

* Indicates a required field

By using this platform you agree to our terms of service and privacy policy.

General comments

Loading...
Povilas S
Povilas S2 months ago
What are the examples of messages people would like to send to themselves (or others) in the future that you have in mind, what is the initial idea?:)
Loading...
Darko Savic
Darko Savic2 months ago
Some examples could be:
- partial seed keywords for a bitcoin wallet sent to your kids. They combine the words to access the funds
- personal birthday wishes to your loved ones for years after you died of cancer
- you and your partner each create a message for each other, to be accessed in X years
- "if anything happens to me" type of insurance messages