These are a few Time To mechanisms that can have some light shun upon them as they can be quite useful to a developer. I will be answering them below in an attempt to explain what they can be used for and why on the @platform.
1 Answers
Time To Mechanisms (Attributes of Metadata)
Any data that is shared between @signs can go through several mechanisms. Some of these mechanisms include TTR (Time To Refresh), TTL (Time To Live), and TTB (Time To Birth).
Time To Refresh
TTR, which is an attribute of the metadata of a shared key, accepts an integer value which represents seconds. The subsequent refresh happens based on the given value: for example, if the set TTR value is 86400, then the refresh happens once in a day (there are 86,400 seconds in a day). Another very important attribute of the metadata is CCD (Cascade Delete), which is a boolean variable (a variable that accepts true or false values). For those who are well versed in SQL and database management, you will already have some understanding of what CCD does and how it functions. If the CCD value is set as true when the sender deletes their original key, the cached key gets deleted on both the sender’s server and the recipient’s server. Correspondingly, if the CCD value is false when the sender deletes their original key, the cached key gets deleted on only the sender’s server and remains cached on the recipient’s server. But why is this useful? CCD is used to avoid unnecessary network calls. As an example: if @alice is in need of @bob’s phone number, she does not need to make a request from her server to @bob’s server to find it, but rather needs only to search locally on her device to find the phone number. Let’s consider a similar example: @alice shares her phone number with her friends @bob and @john. A few months later, however, @alice purchases a new phone plan, resulting in a new phone number. If @alice has her @sign’s TTR variable set to true, once she updates her old phone number to match her new one, this updated value will also be reflected on @bob and @john’s devices. @alice also has the ability to set a specific time, in seconds, for when the new phone number will be cascaded on shared servers (this is TTB, which is described later). This can be 10 minutes, a day, or whatever specific amount of time she defines. This function can be quite handy, especially if someone is constantly updating values on their server. This prevents a high density of calls and requests whenever someone wishes to see what new values exist on a shared server.
Time To Live
TTL (Time To Live) is quite self-explanatory: it defines how long data will live on a server. Anyone with an @sign has the ability to upload information on their server and define how long it stays on the server before it is automatically deleted. If @alice wishes to share her summer vacation getaway location as her current location, she has the option to share that summer vacation location for as long as she plans on being there! To really take advantage of a mechanism like this, developers can combine it with other Time To commands to make life for themselves and those they share their information with easier. Say for instance Alice lives in sunny San Francisco, and owns a vacation home in Spain. With mechanisms such as Time To Refresh and Time To Live, Alice has the ability of travelling to her vacation home for several weeks, uploading her current location as Spain, and setting that information to live on her server for the several weeks that she will be staying at that location.
Time To Birth
Another Time To mechanism that is utilized within the @protocol is the Time To Birth mechanism. This mechanism allows individuals to upload information to their secondary server and have it become activated after a specified amount of time, in seconds. During the time that the data is not ‘active’, any recipients of this information will see the ‘null’ value in place until the activation has occurred. For example, if @alice wishes to upload a web URL of her personal website after she has completed it, she can simply specify that the URL value can be uploaded to her secondary in exactly 1 days’ time. Until the value is updated a day later, @bob can only see that her website URL is ‘null’.

- 21
- 2