I'm using branle (https://branle.fiatjaf.com/) as my client and you can follow me with my pubkey: 22e804d26ed16b68db5259e78449e96dab5d464c8f470bda3eb1a70467f2c793.
You can find my pubring on my bio after following me.
There's no ability to discover others at this time!
> I'm using branle (https://branle.fiatjaf.com/) as my client and you can follow me with my pubkey: 22e804d26ed16b68db5259e78449e96dab5d464c8f470bda3eb1a70467f2c793.
It isn't too hard to improve upon the status quo in various ways when you just drop a key usability requirement (in this case, the need for human-memorable 'handles').
It is worth reading 'Why Johnny Can't Encrypt' (1999) [0], 'Why Johnny Still Can't Encrypt' (2011) [1], and 'Why Johnny Still, Still Can't Encrypt' (2015) [2].
That's true, but you can disconnect those requirements on the server side.
E.g. a "name/profile to key/value" service would be useful for more than this.
If people want mastodon style handles, for example, it's easy enough to create a mapping that can leverage DNS for example to let you query for a matching pubkey in a cacheable and easily scalable way and without the need for that to be built into the messaging protocol.
That's only true if you choose to introduce a global namespace. There's nothing requiring you to have just a single such catalog of users as long as the canonical reference is the pubkey any more than the contact list on my phone requires you to name people the same on your phone.
(and in fact on reading the protocol specs, they do have a way for relays to publish mappings [1] . EDIT: and that would seem to make it possible for crawlers to crawl relays to assemble non-canonical catalogs fairly easily).
There are downsides to having multiple namespaces, such as e.g. that there's no guarantee that your client will be able to map a given pubkey back to a human-readable name and/or dealing with collisions between mappings from different sources, of course, but this is reasonably well thread ground.
Sure, you can have multiple namespaces, and each would have to be censored, but that's about as difficult as playing whack-a-mole with multiple domains pointed at an IP address.
If you can censor the catalogs you can censor the relays. Not least because the protocols allows the relays to serve up catalogs of name to pubkey mappings. Having this lookup functionality makes no difference at all to the ability to censor. If you have an issue with the censorship resistance of this you have an issue with the core concept of this project.
That's fine. But it's entirely independent of whether or not you provide a lookup mechanism for names.
No, you don't. You can have DNS-based aliases to pubkeys, and then people will follow pubkeys and interact with pubkeys, not with the DNS aliases. So if these users are censored later from the DNS then they still keep their identity, their contacts, their followers etc.
The analogy would be valid if IP addresses were permanent and DNS was only consulted once -- and then communication between these two parties was done directly through the IP forever.
Missing the point, which is that the lookup doesn't need to function or be available for anyone but the person composing the message at the time they compose it. It can be entirely private, entirely public, or a mix. What gets transmitted is the pubkey. Optionally the relay can provide a mapping, which may be globally consistent or entirely based in some private mapping.
Users just need a catalog which includes the keys of people they care about. The relays can backfill this information. You have little reason to know mappings for users whose messages you're not seeing, and if the messages are not censored the mappings won't be either.
You could even deterministically map pubkeys to handles with something like bip39. it won't be pretty but it will be unique, human-readable and uncensorable.
YJCE identified a lack of usable concepts as the root problem. Human-memorable 'handles' actually make things worse in that they add in another concept that the user has to learn about and understand. The idea that the ridiculously large number represents a human identity is very easy to comprehend and the user can not avoid contact with that number in a system like this. The number is the identity.
Usability and convenience are two different things. A system that is difficult to use might be easily understood by the user and vice versa.
the eth guys have solved this with ENS, you could add your public key address in your ens record if this ever becomes a thing. Then you just tell people to add me <myname>.eth
Lack of discoverability is often a weak spot of decentralized social networks that don't have a public firehose. Secure Scuttlebutt, Twtxt, Bogbook — and now Nostr — all suffer from this, and new users end up looking at an empty timeline and shouting into the dark.
I once wrote a tool in C# that used Putty behind the scenes to connect to routers (and hop through them) and collect interface metrics. Back in 2009 :)
Customers are misled by the common wording that is used in the current digital marketplaces. The wording needs to reflect the fact that we are just getting a revocable nontransferable license to a digital product or service, and that in no shape or form the customer owns such digital assets.
Instead of "Buy" perhaps it should be "Purchase license" or "Acquire license".
Instead of "Purchases", it should say "Licensed products/services".
The bank cartels probably won't last long, just wait until money becomes mostly decentralized and digitalized. We'll finally be able to use our money without limits or immoral intermediaries.
Have you tried sending $10,000 or more between two "high risk" countries, like from Nigeria to Ecuador? There are so many limits for most people using banking today, where your money gets stuck in multiple places before you "verify" this and that, and then transfers take multiple days if they even get approved in the end.
Bankrupt governments also control what money you can receive.
Example is Lebanon where if you send someone US Dollars, they’ll receive it in the local currency which is under hyperinflation.
The central bank governor (government too) there is pure evil and is a US political pawn. I know it sounds outlandish, but if you look into it, you almost wont believe its real.
