User @npub1z34a5nkxjv5rq5p7unuw3d3xh4an54uyyv4cys96zhyvhlu6qlxs4qnh9r was seen connecting to #Nostr in the past day with IP 49.228.240.73. https://iplocation.io/ip/49.228.240.73 #NostrExposedIPs
User @npub1jlu3zyj7f2hacdrrmy7jpny9f7nnvuxt2flrasjtmgut90502xqqtsx4rf was seen connecting to #Nostr in the past day with IP 79.169.176.94. https://iplocation.io/ip/79.169.176.94 #NostrExposedIPs
User @npub1py6vyt342rw7jfxdprqq8jyxfectm9ju2ag633v4kmrz3j82j6gqtzfxja was seen connecting to #Nostr in the past day with IP 175.39.229.156. https://iplocation.io/ip/175.39.229.156 #NostrExposedIPs
User @npub1wtec56wnla0gccr85lv8fecljnawa5vx6ueu4yy7ydwx5sf5slpswajsf0 was seen connecting to #Nostr in the past day with IP 97.115.253.254. https://iplocation.io/ip/97.115.253.254 #NostrExposedIPs
User @npub1axkh7zyats2ypljcqzclndswzs9rrxcz9zjsqtt0re40gmsxrz3swm58z7 was seen connecting to #Nostr in the past day with IP 80.203.118.87. https://iplocation.io/ip/80.203.118.87 #NostrExposedIPs
User @npub1jvlfnl8dgq3cdwan09xmxj82zq5d6w2lvkggvqqa4spsc9pu8mwqyh5esm was seen connecting to #Nostr in the past day with IP 27.34.76.55. https://iplocation.io/ip/27.34.76.55 #NostrExposedIPs
User @npub1xrja8ekfnzvecwds4zqzf7zlqlervty7wkyl055t8x0jn93f0rds7xrhk7 was seen connecting to #Nostr in the past day with IP 193.32.127.135. https://iplocation.io/ip/193.32.127.135 #NostrExposedIPs
User @npub1llna4n44wdp27s60rlmkquzzmd0dfwdepl4kl4rquptn6dy8cqrq5pk9k5 was seen connecting to #Nostr in the past day with IP 45.83.104.137. https://iplocation.io/ip/45.83.104.137 #NostrExposedIPs
User @npub17qrcn83n26vctnm6yrvlcgcm7gs863eut82h6ckh9vyhdwwl86nq6klzh2 was seen connecting to #Nostr in the past day with IP 172.58.166.120. https://iplocation.io/ip/172.58.166.120 #NostrExposedIPs
User @npub1qqqqqqqrxtrcx8vut2vlrqa0c2qn5mmf59hdmflkls8dsyg9vmnqsclxwk was seen connecting to #Nostr in the past day with IP 8.46.89.33. https://iplocation.io/ip/8.46.89.33 #NostrExposedIPs
User @npub1dg9cl3ztaga3lk524v3qjrujhvfc0dvdu3p6ckmkpkmsq6l7dtwqzvyq97 was seen connecting to #Nostr in the past day with IP 57.128.96.115. https://iplocation.io/ip/57.128.96.115 #NostrExposedIPs
User @npub1rtv0t567ameym4hgmyljf0kmym85kpe2dsfkhnwe9ylvmwmzgjrqc4e7y7 was seen connecting to #Nostr in the past day with IP 161.29.247.171. https://iplocation.io/ip/161.29.247.171 #NostrExposedIPs
User @npub198auqkkwueclk4u3st9r8v8yrdz4hv0e2e9epg7c7teemm3lyausht0p3g was seen connecting to #Nostr in the past day with IP 146.70.165.157. https://iplocation.io/ip/146.70.165.157 #NostrExposedIPs
User @npub1hklphk7fkfdgmzwclkhshcdqmnvr0wkfdy04j7yjjqa9lhvxuflsa23u2k was seen connecting to #Nostr in the past day with IP 95.99.114.42. https://iplocation.io/ip/95.99.114.42 #NostrExposedIPs
User @npub1lhezms58jx4yer60y3wzldc83fdez3j4rc4ue3edhz5qv3wxfsgqhhw94n was seen connecting to #Nostr in the past day with IP 24.127.246.71. https://iplocation.io/ip/24.127.246.71 #NostrExposedIPs
I intend to twist some nips to see what happens.
So, I've been studying #Mostr, and I think it's bad for #Nostr. Nothing against the Fediverse, I just don't think it follows the right philosophy. Normalizing it is a threat to sovereignty. Personally, I recommend muting all Mostr NIP-05s.
I am not calling for Mostr's destruction, but perhaps tools for clients and relays to mitigate custodial account services like Mostr. A single service shouldn't dominate the timeline the way it does, unless the user wants it to.
Let's also face the basic truth: Not your keys, not your account. Mostr holds all the nsecs. They are generated like this:
=====
/** Generate Nostr keys from a seed. */
async function generateKeys(seed: string) {
const privateKeyBuff = await getDigest(seed);
const privateKey = secp.utils.bytesToHex(new Uint8Array(privateKeyBuff));
return {
privateKey,
publicKey: secp.utils.bytesToHex(secp.schnorr.getPublicKey(privateKey)),
};
}
/** Get Nostr keys for an ActivityPub ID. */
function getActorKeys(apId: string) {
return generateKeys(Conf.secretKey + ':' + apId);
}
=====
Where "Conf.secretKey" is a seed value generated with "openssl rand -base64 48".
This is definitely a secure way to make nsecs, but it also secures every account with the same private key. Were that key to be compromised, it's a single-point-of-failure. A staggering number of trusted accounts could be botted in an instant.
That key is stored in plaintext inside of a "config.ts" file on the Mostr server, so we're really just one zero-day away from an issue. We really shouldn't trust accounts like these by default.
Even if nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 is the most trustworthy person in the world, letting one person own that many trusted nsecs is a bad idea. I'll keep repeating this term till it sticks: ZERO-TRUST.
Also, while I respect Mostr being an open-source project, that in itself is a threat given what Mostr does. Standing up your own Mostr is trivial, but could you imagine two Mostrs? That's immediately a spam problem, and probably in invitation to cause a loop to form somewhere. Imagine 10 Mostrs; complete chaos. Nothing is preventing this.
And, just a petty complaint, but everyone on Nostr identifies themselves by npub, but on the ActivityPub side of Mostr, Nostr users are identified by hex pubkey. Fixing this now is basically impossible, and it hurts user-friendliness. That's not our problem though.
That said, a fediverse/nostr bridge could be realized on a per-instance basis eliminating the single-point-of-failure, but increasing the attack surface by adding custodial keys to multiple instances.
I can't think of a sustainable way do make it non-custodial on a per-user basis that isn't just a crossposter.
So, I've been studying #Mostr, and I think it's bad for #Nostr. Nothing against the Fediverse, I just don't think it follows the right philosophy. Normalizing it is a threat to sovereignty. Personally, I recommend muting all Mostr NIP-05s.
I am not calling for Mostr's destruction, but perhaps tools for clients and relays to mitigate custodial account services like Mostr. A single service shouldn't dominate the timeline the way it does, unless the user wants it to.
Let's also face the basic truth: Not your keys, not your account. Mostr holds all the nsecs. They are generated like this:
=====
/** Generate Nostr keys from a seed. */
async function generateKeys(seed: string) {
const privateKeyBuff = await getDigest(seed);
const privateKey = secp.utils.bytesToHex(new Uint8Array(privateKeyBuff));
return {
privateKey,
publicKey: secp.utils.bytesToHex(secp.schnorr.getPublicKey(privateKey)),
};
}
/** Get Nostr keys for an ActivityPub ID. */
function getActorKeys(apId: string) {
return generateKeys(Conf.secretKey + ':' + apId);
}
=====
Where "Conf.secretKey" is a seed value generated with "openssl rand -base64 48".
This is definitely a secure way to make nsecs, but it also secures every account with the same private key. Were that key to be compromised, it's a single-point-of-failure. A staggering number of trusted accounts could be botted in an instant.
That key is stored in plaintext inside of a "config.ts" file on the Mostr server, so we're really just one zero-day away from an issue. We really shouldn't trust accounts like these by default.
Even if nostr:npub108pv4cg5ag52nq082kd5leu9ffrn2gdg6g4xdwatn73y36uzplmq9uyev6 is the most trustworthy person in the world, letting one person own that many trusted nsecs is a bad idea. I'll keep repeating this term till it sticks: ZERO-TRUST.
Also, while I respect Mostr being an open-source project, that in itself is a threat given what Mostr does. Standing up your own Mostr is trivial, but could you imagine two Mostrs? That's immediately a spam problem, and probably in invitation to cause a loop to form somewhere. Imagine 10 Mostrs; complete chaos. Nothing is preventing this.
And, just a petty complaint, but everyone on Nostr identifies themselves by npub, but on the ActivityPub side of Mostr, Nostr users are identified by hex pubkey. Fixing this now is basically impossible, and it hurts user-friendliness. That's not our problem though.
Thanks for bringing privacy to the forefront. Few read the respective nostr github project documentation on privacy. Your method of exposing privacy on base nostr protocol has been effective.
> hardly any moderation tools
Despite this, the discourse is more civil than that of twtr. Maybe it’s a function of nostr’s tiny size, and lack of algos.
nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 and nos social are as far as I’m aware thinking and developing most on moderation tools.
I don’t know how far they’ve gotten - that said one of the benefits of nostr is you don’t have a mandatory moderation curator in a WEF stooge. You can have a feature where you choose your own moderator - for instance you can choose Jack.
nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk implemented web of trust network hops filter more than half a year ago on Iris messenger.
> no centralized development
Yes, this is a feature. Otherwise we’ll get another closed big tech gulag.
You are more than welcome to submit PRs to Damus, and I’m sure many others will happily review patches. Nearly all of nostr is FOSS, and lead devs welcome patches.
Example code and issues https://github.com/damus-io/damus
1) Once you have an account established and are following people it is mostly fine, but it's hard to browse the global feed without seeing strongly undesirable content such as lolicon (or worse). This is a natural consequence of being censorship-resistant, but it will scare new users away. I'm excited to see how this can be reigned in without harming the free speech of other users.
2) By "centralized development", I just mean any standard unifying practice for development. Centralizing a core Nostr codebase under GPL would keep it property of the people forever, while making sure all bugs and weaknesses are patched for everyone. Everyone doing things their own way is a recipe for disaster. Death by a thousand cuts.
3) I have never used Damus, so nothing I've uncovered is specific to them. Finding a weakness in Nostr means every affected Nostr project needs to fix it independently. Even I don't want to write that many bug tickets.
Top flaws?
1) Reckless NIP implementation. Too many features with deleterious side-effects.
2) Poor privacy controls. Way too easy to leak PII.
3) Poor key management. One big exploit could compromise large numbers of accounts.
Ad for moderation, I just worry about the commonality of extreme content that will scare away new users.