-- import: ft

-- ftd.image-src src0: https://ftd.dev/static/images/logo.svg
dark: https://ftd.dev/static/images/logo.svg

-- ftd.image-src src1: https://ca.slack-edge.com/T016XLVEW4W-U0174K0BDB5-gecc6caf7069-512
dark: https://ca.slack-edge.com/T016XLVEW4W-U0174K0BDB5-gecc6caf7069-512

-- ftd.color color1: rgba(153, 148, 148, 0.3)
dark: rgba(153, 148, 148, 0.3)

-- ftd.color color2: rgba(13, 131, 225, 0.23)
dark: rgba(13, 131, 225, 0.23)

-- ftd.color color3: rgba(255, 255, 255, 0.8)
dark: rgba(255, 255, 255, 0.8)

-- ftd.color 2196F3: #2196F3
dark: #2196F3

-- ftd.grid:
slots: header header | sidebar main | sidebar footer
slot-widths: 20% 80%
slot-heights: 10% 81% 9%
width: fill
height: fill

--- header:
slot: header

--- sidebar:
slot: sidebar

--- main:
slot: main

--- footer:
slot: footer


-- ftd.row header:
width: fill
height: fill
padding: 10
border-bottom: 2
spacing: 20

--- ftd.image:
src: $src0
height: 32
align: center

--- ftd.text: FTD Journal
align: center


-- ftd.row footer:
width: fill
height: fill
background-color: $color1
spacing: space-between
padding: 20

--- ftd.text: LinkedIn

--- ftd.text: Facebook

--- ftd.text: Gmail



-- ftd.grid sidebar:
width: fill
height: fill
slots: header | main | footer
slot-heights: 10% 80% 10%
background-color: $color2


--- ftd.text: About AmitU
/style: bold
slot: header
align: center

--- ftd.column:
width: fill
height: fill
slot: main
padding: 20
overflow-y: auto

--- ftd.image:
src: $src1
height: 50
align: center

--- ftd.text: Amit Upadhyay (CEO fifthtry)
align: center
margin-bottom: 40

--- ftd.text:

Amit Upadhyay is the Founder and CEO of FifthTry.com, an IIT-Bombay graduate, and
open source contributor. This is his personal blog.

Take up one idea. Make that one idea your life.

Think of it, dream of it, [live on that
idea](http://www.paulgraham.com/top.html).

Let the brain, muscles, nerves, every part of your body, be full of that
idea, and just leave every other idea alone.

This is the way to success.

– Swami Vivekananda

> My name is Ozymandias, look at on my works ye mighty and despair.

First, master fundamentals. Then, play infinite games. — James Stuber

--- container: ftd.main

--- ftd.row:
width: fill
height: fill
slot: footer
spacing: space-between
background-color: $color3
color: $2196F3
padding: 20


--- ftd.text: Live Well!! Eat Well!!
align: center


-- ftd.column main:
width: fill
height: fill
overflow-y: auto
padding: 40

--- ft.h1: FTD Journal

Thoughts: Browsing History
Readership Tracking
Linking Using Package Dependency
So links never break (and original author can keep updating document URL at whim).

Git Tracking
More than one fpm package per git repo
Article Out
(on how having article.page allows us to get just the content of a page, without header/sidebar/footer etc).

Thought: Package Identity
2nd Jan 2022

Still can’t believe 22 is here! So I have been thinking about fpm update recently and came across nostr that
implements something very close to what I had in mind.

I kind of consider nostr design the right design, good balance between centralised (prone to attacks, censorship etc)
and “pure” peer to peer (complex, less reliable etc). Maybe there are issues, but to me it sounds good.

So we know how to distribute packages. What is missing is package identity. Package names depend on DNS if you buy
your own domain, and with others, eg github if you host on <username>.github.io etc. So how do we ensure you really own the package identity? That you can move from .github.io to something else without losing people who may be interested in your content.

Traditional way requires you to do a redirect from old to new. But this relies on old service still running, often companies come and go, domain can expire or sold to someone with no interest in honouring the old contracts.

If not domain name then what? One candidate is cryptographic keys. But they are too hard, at least when you are targeting billions of publishers, like Twitter and Facebook does. Eventually your FPM packages should be your twitter/Facebook profile, but how do you manage identity?

WhatsApp etc, E2E, End To End-Encryption systems rely on some shared identity, eg a phone number of email address as a convenience, and then they generate some keys behind the scenes, you can see the fingerprint of your keys in whatsapp for example, and verify each others identity (phone number appears to be the identity from the layman’s perspective, but its backed by strong cryptographic foundations).

So let me repeat, when you are sending a message on WhatsApp, you think you are sending it to a phone number, but WhatsApp has internally exchanged some encryption keys with that contact, and its going to that key.

Let me say it in a more formal way, in PKI, whatever that might be, anyone can generate a key pair, a private key and a public key. This key pair can be considered an identity. When you send a message it goes to someone, that someone needs to be identified, and how we identify them can be considered their identity. What you can do is encrypt the message with the public key of the recipient, and only the corresponding private key can de-crypt the message.

So in this sense, a key pair can be your identity. But key pairs are just numbers, and unlike phone numbers, they are much bigger. So exchanging these numbers is not fun, it’s opaque, no one can remember them, nor can see what they are referring to if we see a huge number representing a public key in someone’s FPM.ftd file as a dependency.

So we need a way for the key pair to get an alias. The domain name is a good alias. If we tread DNS as alias, not the source of truth, things are much better. Identity moves are rare, but they do happen. People switch providers, people may want to move from Github Pages to another service, and back. Once someone starts following someone, such moves should not affect them, the followers should continue to get updates despite name changes. So how do we achieve this with PKI and aliases?

Imagine Github Pages implemented our protocol, this is how it could work. They generate a key pair for you when you sign up. This is important if we want billions of people to use services. Most people are not going to want to bother with all this. This is what WhatsApp/Telegram do to deliver strong cryptographic guarantees (at least by design/promise, implementation is another matter) to masses.

So when you create an account on any of these services, they create a new unique identity (key pair) for you. You start using that service, you gain followers, and say you get serious. This is the point you will bother with all this identity business details. Now you have say 100s of followers and you want to move to a different provider, without losing the followers (without breaking 100s/thousands of packages that depend on breaking).

At this point you will now claim your identity. You install another app, offline only for strictest guarantees, and generate your real identity, real key pair.

Now if Github Pages etc are acting in good faith, they will let everyone know that they are temporary guardians of your identity, that you have not yet claimed your identity, and the moment you do so they will cooperate. If they chose to act in bad faith, charge you money for you to claim your identity or not let you do it while initially promising that they will, then you could lose follower, but hopefully word will spread and people will shun such services.

So the temporary guardian of your identity can accept your real identity keys, and everyone who is following your via <username>.github.io now learns of your true identity as well (and that Github is an intermediary working for you for now, via you signing the Github generated keypair with your real identity).

So real identity has always been the keypair, but we would be using the domain name. We need a distributed store of keypair to DNS mapping, so you can switch the domain for your keypair. Some sort of “key server” is needed. Your followers where initially thinking that the Github generated keypair was the true identity, but since you update your identity, github will notify them about the true identity and your FPM will now store the true identity of what you are following.

We also will have to allow for “key revocation”, say one of the guardians went rogue, got bought out, hacked etc, and starts sending updates on your behalf to your followers, you had signed that key-pair with your key, so now you have to revoke that key-pair. The key-server can do that as well.

So the protocol is: in FPM.ftd you see domains. You keep a cache of domain to keypair id on your file system. Periodically you check with key-server if the domain for any keypair has changed, if so fpm commands start reporting warnings that domain entries are out of date, please update ASAP. fpm can now chose to, if you so want, start using the latest entries from key-server for the identities, so say if dependencies say you are publishing on <username>.github.io, but since key-server says domain moved to <username>.com, fpm will start fetching from <username>.com.