![]() Personally, I don't really care about all that. Any of that will work these days (or even a combination of all of them). If all else fails, there is always crowdsourcing and launching some new cryptocurrency and/or sell a series of badly designed bitmaps as NFTs. None are 'impossible', obviously, not in this era and age: you need a few buzzwords, a few business connections, a bit of luck, a great presentation, and Bob's your uncle. Getting seed capital to keep it going and pay salaries to full-time employees - as opposed to eager volunteers - is another. Getting traction for one's home-cooked new protocol is another thing. ![]() Especially if we are aware of past solutions, their weaknesses, their pitfalls, and their long-term threats (such as Keybase's servers going down because 'Zoom wants it so'). Starting something from scratch is not necessarily a Hard Thing To Do. Launching a new federated, Web3, whatever-buzzword-is-trendy-today from scratch is reasonably simple these days there is a lot of code out there, as well as a lot of algorithms, solutions, and even complex mathematical theory behind things such as DAGs, Merkle trees, and whatnot. Those who embraced Keybase (yours truly included) do not want another protocol, another software solution, another Next Best Thingy to install, update, and maintain. While discussing whatever alternatives exist to Keybase is commendable, and I personally enjoy learning about those, I feel that they might distract a bit from the original intention of this feature request (if I may call it that). ![]() I see that the discussion tends to move away from the essential (get an open-source version of the Keybase server) to the marginally significant issues (replacing Keybase by ).
0 Comments
Leave a Reply. |