Last Notes
The endless march of enshitification plods relentlessly onward.
You cannot follow someone privately on your main Following list. The Kind3 event has no way to represent such a concept.
But you CAN follow people privately on any other list you create for yourself.
@npub1acg…p35c I'm running gossip on macos, self-compiled from master and currently up to date with github. I no longer see any UI to toggle persons on my lists as private or public. Maybe I just can't remember where that used to be? Or is it gone permanently or temporarily? Or is there a bug?
Here are a couple worthwhile posts on baking (mainly wholegrain) bread with sourdough starter:
https://breadtopia.com/demystifying-sourdough-bread-baking/
https://breadtopia.com/slow-lazy-sourdough-bread/
Great data point. So I still haven't found a likely culprit.
Fwiw, another data point. I've been using graphene for over a year now and it has been super stable and reliable for me all along. When I first got a pixel to try it out it was very much experimental for me because I just assumed that all kinds of stuff wouldn't work. But after a week of use it was clear to me that it worked better in every way than my Samsung phone on regular Android and I made the full switch.
Where I live out in the country we have shit cell service so I rely on wifi calling and text. This was the primary thing I figured wouldn't work so well. But it turned out to work way better than my other phone.
"Reticulum is the cryptography-based networking stack for building local and wide-area networks with readily available hardware. It can operate even with very high latency and extremely low bandwidth. Reticulum allows you to build wide-area networks with off-the-shelf tools, and offers end-to-end encryption and connectivity, initiator anonymity, autoconfiguring cryptographically backed multi-hop transport, efficient addressing, unforgeable delivery acknowledgements and more."
https://github.com/markqvist/Reticulum
It might be a bit too persnickety at present. I may need to add another index and allow more filters. I'm not sure.
Testing Chorus
@npub1acg…p35c
That is a reasonable optional way to do it. I'll leave this up to @npub1000…vwqk and @npub1hlq…z5wg . They handle the UI/UX stuff.
Hey @npub1acg…p35c, I think i remember seeing that you use or have used Amethyst sometimes. I'm noticing that I like one thing that Amethyst does that gossip doesn't do (yet?). When looking at a reply, I like how Amethyst puts a "preview" of whatever note the reply is to within (above) the rendered reply in the timeline.
For me this seems like better UX than just having the link to the replied-to note which takes you to the full thread timeline. I like that link too because I often want to click into the full thread view. But there are a lot of times that having only the context of the direct parent of a reply is plenty and it would be a lot more efficient to not need to click over to the full thread in those cases.
Cool - thanks for the heads up.
Not sure if I am understanding what you are saying but what I hope amethyst does when I set it to connect via tor / orbot is that if orbot is switched off or unable to connect to the onion network for whatever reason, then I want amethyst to not connect to anything anywhere - I want to see a blank screen in amethyst in that case which will let me know that something is wrong with my connection.
IOW if I say connect via tor / orbot, then don't connect (of fail back) in the case of tor / orbot not being connected.
otherwise i will never know if I am actually reading and posting via Tor or not unless i am constantly checking whether orbot is connected.
Sorry, but what's this guy going to do when his pirate ship gets blocked "from port" by other Mastodon instances?
While we're at it we should also #banraybans. As well as any other glasses / sunglasses manufacturers teaming up with the likes of poop-for-brains CEOs like zuck to put ubiquitous surveillance devices on the faces of every fucking human walking the streets of earth.
I'm definitely planning to get long form content from Wordpress -> nostr working in my nostrtium plugin as soon as I have some clear time to dive into it. I've had no time to work on it for some months now, but I hope to have a window sometime in February when I can work on this.
So then you still want your laptop to be your laptop but you prefer a different framework of defining what that means in principle and in practice than the conventional, mostly western developed-world legal frameworks that currently dominate. Is that accurate?
Although I don't really like this term very much (because I think jargon in general seems to obscure what it's trying to disclose), I find myself mostly agreeing with what libertarians call "natural law" most of the time that they use it, and I feel like property - possessions - mostly have a pretty obvious "natural law" set of rights and wrongs around them that my dogs seem to understand perfectly well without any codification.
When there is contention between my dogs over some property, most often the assertion of natural law will carry and often the less dominant dog will prevail when she has natural law on her side. But there are also occasions when the provenance of some goody is not clear and in that case, might makes right in the dog world and the spoils then invariably go to the stronger, more dominant dog.
For all its warts, the capitalist codification of law surrounding property mostly aligns pretty well with my notion of natural law around property and mostly (*mostly*) protects humans from might makes right losses. Under your interpretation of libertarian socialism, how would property contentions be managed?
That's an interesting political philosophy.
On that Wikipedia page it says that it differs from other forms of libertarianism by its rejection of private property.
Do you reject the notion of private property? And if so, does that mean all so-called property or only certain classes of property? IOW if we ran into each other at a coffee shop and I chose to walk off with (what I would call) "your" laptop, would that be congruent with your philosophy?
Good on both of you then.
And I can only take credit for coding. @npub1000…vwqk came up with the design.
Thanks. I just did that yesterday. I missed the 'focus' issue the first time but @npub1000…vwqk was quick to correct me 😅
@npub1acg…p35c I like the new gossip login screen. Very polished. Also nice that the insertion point defaults to being active so you can just start typing or pasting right off the bat without clicking or tabbing into it.
I'm able to use lists in X accounts that are private / non-posting. But the UI for creating lists has become extremely obscure and unintuitive. You maybe have just not found where / how to create them?
In the good old days, tweetdeck made it very easy. Also when "free speech champion" twitter allowed 3rd party clients, tweetbot (by tapbots) also made it easy and so clean to use. As far as I can tell, twitter under elon is hell-bent on making it entirely un-usable. Aside from people knee-jerk disagreeing with his politics, I think the UI devolution of twitter is probably driving a lot of people to nostr.
On my brief read of the whole project, 'reticulum' is not a name for a social media protocol but is instead the name of a completely decentralized, encrypted, cryptographically addressable, un-surveillable networking stack that could (should?) replace TCP/IP altogether. It aims to be the plumbing that the Internet should have had from the get go.
https://image.nostr.build/8a2482221da05b2c8199f599d7b2a042b88f81d09d73e3ff0084f744e79b85d6.png
Within the small reticulum ecosystem, there is a social media / chat protocol that is built on top it which is called LXMF (https://github.com/markqvist/lxmf).
I can't get lists to work on X. I think maybe because my account can't post?
Yeah, I use lists extensively on X and it was one of the two things that I miss(ed) a lot in nostr until now. I love this new gossip list implementation. Thanks Mike!
(The other thing I miss is the UI ability to assemble my lists in parallel tabs in one wide window like tweetdeck)
Reticulum is very interesting - thanks for posting that.
nostr devs might be interested in this repo which is a lightweight messaging format built on top of the reticulum networking stack. There is considerable overlap with nostr functionality: https://github.com/markqvist/lxmf
Embarrassed that I can't keep up with the NIPs, but that's awesome.
It means what NIP-51 defines it to mean. The private entries are encrypted into the contents of the list so they are shared with you on other clients, but not visibile to other people looking at the event.
Really excellent work on this. Love the follow list implementation.
If I toggle "public / private" to private for a person, does that mean that if I publish that list the person who is set as private will not be part of what is published (i.e. I'm following them only from this instance of gossip and nobody can trivially [without access to behind the scenes relay data] see that I am following them?
you gotta script it. It's worth the up-front investment.
I'm with you. Please post if you run across an acceptable solution. I will too.
I don't know why the post I'm replying to has a content warning. My old man fingers and eyes don't know how to use this little phone client very well.
That's funny. I also mostly use a desktop over starlink and use gossip (though I happen to be composing this on Amethyst on my phone at the moment) and I currently follow fewer than that so yeah, for me there is no performance bottleneck, no battery issues.
I also run a personal relay based on strfry with my own minor modifications and I very much like the idea of client proxies. But I also grow most of my own food. And while friends who come over admire my garden and tell me how much they'd like to have one like it themselves, everyone knows that the vast majority of people are not gonna be spinning up a VPS to run and maintain a proxy relay.
I think needing to even subscribe and pay for a proxy that someone else runs is going to be too big an adoption hurdle for nostr to get beyond fringe usage in the age of downloading an app to your phone that "just works" in about 15 seconds. I hope I'm wrong but that's how it seems to me.
For me, the problem with even "50 or 100" big relays that everyone uses is that each and every one of those relays becomes a target for government's that think their job is to keep people from saying things they don't want them to say. If there is such a target set, no matter the intentions of the people operating those relays, the whole thing is too vulnerable.
I think the only way it's not vulnerable is if relays are tiny, cheap, stupid and ubiquitous so that it's effectively impossible to police them by sheer numbers. I recognize that world has all the performance and scaling issues we are talking about and it also may not work in the sense of getting past fringe adoption. But again, I'm here for the free speech absolutism, not for the stickers, badges, likes, follower counts, etc.
Most of my opinions about nostr's architecture come from a conversation I had with a friend of mine who used to work at Twitter. He explained that Twitter is only able to deliver relevant content quickly by pushing it to a huge network of special purpose caches. This is easily done with nostr relays in theory, the hard part is coordinating how caches (relays) get primed. I think some combination of push and pull will be necessary - if indeed the problem can be solved without central coordination.
I don't expect people will spread out over thousands of relays. Things naturally gravitate towards centralization. We don't all use thousands of different web browsers or even thousands of different email providers (anymore)... people learn which ones are the best and people naturally gravitate to and centralize upon those. The same will be true of relays. Most people will use the main group of 40 or so relays (which might even whittle down to 10 or so over time, who knows) that everybody knows work well. And that begs the question "they why bother with the outbox model?" Because the outbox/inbox model allows that 5% of people who want to do their own thing, to roll-their-own, to have custody of their own notes, to be sure they are not being censored, to do so without losing their audience.
I hope the fan-out never gets crazy large. I hope I'm right that most people will naturally tend toward using the same popular relays. But if it does get large, I think proxy solutions are going to be the way to manage it.
I didn't realize filter.nostr.wine was such a thing, or that you were involved with it (so much going on in nostr to keep track of who is doing what).
I personally use a desktop computer over a starlink interface and I follow about 170 people. Right now I'm connected to 31 relays, which is far fewer connections than this computer can make. So it is working great for me.
But I recognize that younger people tend to only have a smartphone and fewer people use desktop computers. And I recognize some people want to follow thousands of other people. That is a difficult thing to make work well in a direct fashion under the outbox/inbox model.
But it can work indirectly. One solution is using a client proxy (which @npub1jlr…ynqn and I speak about briefly on his podcast that will be coming out in a week or so) which is basically an internet server which acts like a client on your behalf on the outside, and presents like a relay on the inside so that your mobile app only needs to make one connection. That can be done right now with zero changes to the NIPs, using the inbox/outbox model, and it solves that mobile phone problem far better than (1) blasting events everywhere, or (2) everybody centralizing on the same relays. Sure, most people won't be running their own client proxy, they will sign up as a customer to a client proxy service. But they can easily move to a different one if the one they are using starts censoring them. And us hacker do-it-yourself types retain the option of running direct.
@npub18kz…x5sz
I think this is right. Unless someone comes up with some magic - which I don't rule out - it's a trade off.
I think a lot of people are not going to be satisfied with anything other than a Twitter clone. And I really think that failing the magic the only way to produce a performant Twitter clone is via some version of a big db controlled by a single entity.
Personally, for me, censorship resistance is way more important than all kinds of things that Twitter has that I don't care about so for me that trade-off is easy to make.
Since I got involved with nostr I've been ranting against doing things that Twitter does that I think are impossible to do (properly) in a meaningfully decentralized protocol. Like counting likes and followers. I mean, of course you can count them as long as you are satisfied with a count that is always wrong and sometimes way wrong and totally wastes resources to compile.
Personally, I'm here to read what certain people have to say. I don't give the slightest shit how many people follow them or how many people like what they say. But what I want from a system like this is different from what others want. I won't ever need to follow more than a few dozen people.
I agree that without decentralization, nostr becomes uninteresting. So centralizing on the same big relays is not an option.
The only alternative to outbox/inbox that I know of is blasting events everywhere, and that has the worse downside of massive resource usage and its scalability becomes more and more difficult the larger the network grows.
I think the downsides of the outbox/inbox model aren't a big deal. They only arise on mobile if you have low battery and are trying to follow a god-awful number of people, or if you want privacy but for some inexplicable reason aren't operating over tor and so you are pissed that your IP address leaked to a server you didn't pre-approve of (even that can be solved with whitelisting).
Sorry I massively oversimplified because I think it's a big picture issue. Of course there is a lot of grey. But essentially there are currently three big picture models. There's one big database (which of course is not really one db, but again simplifying) aka Twitter, there's semi decentralized where independent servers federate aka mastodon, and there's fully decentralized like nostr currently is trying to be for the most part.
I'm not trying to be dismissive or sarcastic. I've tried to come up with something better and I can't. But that doesn't mean someone else couldn't. Maybe you will. I hope you do.
Gotta say I’m pretty blown away by this response. If the most simple and obvious arguments have no rebuttal, then we indeed desperately need to come up with something better. I assumed those pushing it had at least thought past level 0.
The choice isn’t gossip model or one single database. Look around, what we have now is already much better than that.
Come up with something better is the exact right response. Essentially at the moment there is a pretty stark choice between decentralization and performance / efficiency.
You can get performance and efficiency by aggregating and thus centralizing data. That's Twitter.
Or you can have the basic nostr model of data spread far and wide under no point sources of control with the trade-off that it's never going to have the efficiency of a monolithic database and the need to invent new optimizations that make it work acceptably well.
The gossip / outbox model seems like the current best basic optimization that retains real decentralization (without which nostr is absolutely nothing interesting at all) and lets clients find stuff.
Come up with something better.
The actual "thing" with lightning is that the whole thing is the biggest kludge in the history of kludges. It's a Rube Goldberg contraption bolted on top of an experimental, unoptimized protocol. It was from the start the wrong solution to the right problem.
There, I've said it. Give me your hate zealots.
Service running behind cloudflare or other ddos protection? Clients trying to connect to service via Tor or other non-conventional connectivity?
I run graphene.
I have orbot running on my phone but not in VPN mode. And I use Amethyst with it set up to connect via Tor through orbot's proxy on port 9050. (Thanks again @npub1gcx…nj5z for adding that)
It works ok - well enough for my purposes. It is much slower than a direct connection and some events and images, videos etc don't download because a lot of stuff on the internet blocks traffic from Tor exit nodes because a lot of idiots do idiotic things through Tor.
On graphene, I use Google Gboard with zero permissions granted: no network, camera, contacts, etc. I think in this state it can do no harm but it works way better than any of the oss keyboards I've tried (and I've tried many).
1 vote for going back to dark grey.
“Open discourse is the central pillar of a free society”
https://westminsterdeclaration.org/
[nostr fixes this]
@npub1sg6…f63m
@npub180c…h6w6
Consider the hypothesis that the interests that control news media content are in favor of a global panopticon.
Cool. My little Wordpress nostr client does the same thing:
https://image.nostr.build/6951e59b7bec513158f5dc7271043c4d975ec42d1a0258139f48c2a6a39a6cb9.png
https://github.com/pjv/nostrtium
Speaking as a jew, "only the jews could make that argument" made me laugh. Not unfollowed.
However, in the case of nations, governments are undeniably chock full of psychopaths.
+1 for obscure demolition man reference.
Although a lot of signage is not in English (though a lot also is), Japan is extremely easy for english speakers. 50% of the people on the street will just walk up to you and start trying to help you in English if you even vaguely look like you might be lost or confused.
What do you think about the idea of using kind 30000's for default saving of follow lists for client interoperability?
Personally, I'd much prefer that my default list of follows was private. I know other people like having public follow lists and having both kind 3 and kind 30000 makes both possible. I just think the safer default is to use kind 30000 for this purpose.
I either don't understand what you're saying or you missed my point.
If my friend bob creates a pubkey to be used to post stuff anonymously but because we're friends, he tells me that pubkey is his. Since he's using that pubkey to post anonymously, he's not going to put "bob" in his kind0. And whatever he may have in his kind0, if I petname that pubkey "bob" so I can remember it's him and then my kind3 list goes up to relays, i just doxxed bob.
I know not to do that. You may know not to do that. I'm not bringing this up for you and me.
If petnames are part of the kind 3 data that clients store publicly on relays then encrypting them would be critical to avoid inadvertent doxxing.
Let's say I have a friend who has a pubkey they share with me that they want to use anonymously. I follow that pubkey and give it a petname. Then I intentionally (with some clients) or unintentionally (with other clients) save my kind 3 follow list to my write relays.
For that matter, maybe it would be better by default to use kind 30000 (from NIP 51) for saving contact lists to relays for client interoperability and then let kind 3's only be for intentionally saving public lists of people for other purposes.
Maybe they think you hate peach.
More on moron glasses.
I'm very much a live and let live kind of person. I don't need you to talk like me or think like me or be like me.
If you prefer or just don't mind having your life surveiled by people you don't know or have any reason to trust, that's ok with me. I think it's stupid but I'm 100% ok with sharing this world with stupid people.
What I'm 100% not ok with is you splashing that stupid on me by pointing your face at me while wearing your little .gov-approved, big brother, meta-ray-ban panopticon ports, piping video of me minding my own business on the street directly into Mark Zuckerberg's anus and then on into the never-forgetting NSA hard disks in the Utah desert.
Starting from October 17, if you are wearing Ray-Bans anywhere near me, you and I will have a problem. A real problem. A serious problem.
I'm cancelling Ray-Bans.
https://image.nostr.build/b984cef510b892534714348338d5119c3732300791a2c82ed61b363fec7c7ee2.png
Thank god for Mark Zuckerberg; now you can BE a jerk without LOOKING LIKE a jerk.
Seriously, starting from October 17, if you are wearing Ray-Bans, you and I have a problem. A real problem.
Exactly. Perfectly said on both. Most especially the parts about keeping the protocol as simple as possible. I worry that nostr is getting too fat too fast.
I also favor you, as nostr CEO, running rampant through the existing NIPs and sprinkling in a lot more MUST and MUST NOT.
@npub16dm…83yd
The answer to all those "what happened to you" posts should definitely be "what happened to YOU?"
https://image.nostr.build/9629484a36ddbd517e6ab974e92d23dca1a7f4636ac3b52b3137c258f0878b57.png
Sorry, but welcome to the other side of "embrace the chaos".
Personally, I favor tighter specs throughout. Discipline is the paradoxical path to freedom.
That will be a fantastic addition to gossip - my fondest wish. The only thing I miss (at all) about twitter is the tweetdeck ability to have separate lists in columns.
You must look at veilid. https://veilid.com/docs/overview/
"Veilid is an open-source, peer-to-peer, mobile-first, networked application framework.
The framework is conceptually similar to IPFS and Tor, but faster and designed from the ground-up to provide all services over a privately routed network.
The framework enables development of fully-distributed applications without a 'blockchain' or a 'transactional layer' at their base.
The framework can be included as part of user-facing applications or run as a 'headless node' for power users who wish to help build the network."
Would have been dead on if they were talking to each other through their devices while sitting across the table from each other.
mine does...
https://cdn.nostr.build/i/b242a45d67e8e01e2d5de2e0e26f23aa4bd9766284e41e1c2cc27c05b6008242.png
Uhhhh... it's Android.
Tried anysoft and I wanted to like it. Gboard is so much better.
My use-case is probably different from yours but I can 100% honestly say that Graphene works better for me as a daily driver than the stock Android on a Samsung A71 that I switched from. I only have one profile. I was expecting to have to spend a lot of time setting things up and tweaking, but it ended up being less than I feared, and since I got the phone set up and configured, it's been surprisingly stable and reliable.
FWIW, I'm using GrapheneOS specifically to de-Google (in the sense of them vampiring my data). I've tried all the open source keyboards and they are all unusable for me. I am running the latest version of Google's GBoard which is the best keyboard for me functionally by many miles.
The beautiful thing about Graphene is that you can install GBoard and very simply give it zero permissions; no networking, no contacts, no microphone, no photos and videos... and then you get a fully functional keyboard and none of the siphoning.
I don't know anything directly about the devs, but grapheneOS works better for me than stock Android and the amount of stuff I am not currently "sharing" with google lets me sleep better.
This is great news. I think if widely well-implemented in relays and clients the gossip model can fix some fundamental issues in nostr that would eventually (under higher adoption) become show-stoppers.
If nostr's functioning becomes critically dependent on some low number of popular relays (which is arguably the case already), it loses its single most important characteristic: DECENTRALIZATION. And those popular relays inevitably become targets of all kinds of interference (hacks, DDOS's, court orders, etc, etc, etc).
If nostr is going to work as a large-scale social media platform (there are plenty of other use-cases that don't depend on this), there have to be LOTS of independent, commodity relays all over the place that are fairly dumb and follow a relatively simple set of common rules.
Live and let die. Also Roger Moore.
Original code is a rush when you get it working. Refactoring gives you the satisfaction of craft. Looking forward to when you push this new code to main.
Thanks. I'm following a handful of AP accounts through the mostr.pub bridge and whether their posts make it to my nostr client seems kind of hit and miss. It's fantastic that it exists at all but I'm wondering if nostr federation is not still a bit alpha.
Also, for people on the AP side, nostr user names are so opaque.
@npub108p…yev6
Sorry to use you as a chatGPT substitute but I don't like talking with algorithms.
Do you happen to know what the simplest (smallest resource requirements), cleanest, docker-based solution is to stand up a small activity pub server that can federate with mastodon? It would be used just to host one or a small handful of related accounts - not for the purpose of creating its own sub-community.
Some years ago when I was looking into the same, I put up an eexperimental pleroma instance. Is that still the way, or something better since then?
All you need is an infinite number of elifs and an infinite number of print statements and you have AI.
Sorry, but until people understand what decentralized means and why it is important to them and to a functioning society... until they DO care about that... we <here> are biding time.
Disintermediated, p2p value transfer is important no doubt.
Disintermediated, uncensorable p2e (everyone) speech is (at the present time) a bigger innovation.
You could take a look at my personal strfry repo here: https://github.com/pjv/strfry_personal_docker - would be easy to modify it to suit your use-case.
@npub108p…yev6 has published a bunch of excellent strfry policy code here: https://gitlab.com/soapbox-pub/strfry-policies/
I use Gboard on graphene and it works perfectly. Only keyboard I can tolerate and I've used a bunch.
The way I have it configured on my phone, Google services is installed but it has zero network permissions. Same with Gboard. Nothing Google on my phone is allowed to network at all.
If it's like it is here (in the US), it will feel pretty damn fast compared with 4G. It varies quite a lot from minute to minute but it's not unusual to see peaks of close to 300 mbit down.
It is very assymetrical though - I don't get near the DL speeds in the UL direction.
Well... there are definitely a few people using it and giving me feedback which is helping me fix bugs. But mainly in answer to your question, yeah, I'm using it for exactly the reason that I built it - to send out announcements of WordPress posts to nostr.
I think building more general purpose tools that would take an RSS feed as an input and generate nostr posts as an output is also a great idea. Not exactly what I wanted, so I built nostrtium to scratch my own itch.
Problem is... if you went far enough with hardware and software it would be far too threatening for the networks to allow such devices and so they would not. So then you'd also have to somehow launch and maintain an alternative global mobile wireless network.
Gotta say that I am extremely happy with a Pixel device (6a) running Graphene OS. I was expecting to have to make a lot of awkward compromises but I have not had to do that. My use-cases are probably atypical but I've been able to set up this phone to do anything and everything that I want and need to do with it and altogether it honestly works better - a lot better in every way that matters to me - than my prior Samsung-on-Android phone that it replaced.
I have starlink in rural usa. I've had it for about a year now and it has been much better than the long distance wifi (WISP) service it replaced.
The customer service has been good when I've had to use it which hasn't been often.
The only negative thing I've experienced so far is already 2 price hikes since I got it. I started at $99/mo and soon after it got bumped to $110 and just recently up to $120.
Still worth it to me given I have no current alternatives that have good bandwidth. That may change soon with expansion of local 5g service providers.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. Nullam sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien. Nam consectetuer. Sed aliquam, nunc eget …
@npub16dm…83yd
https://nostr.build/i/87ae6a8398ef04d994f3a1cf0018d599fa2cd6f8d97d6602b8c358b3ac20c00b.jpg
If this was really a true statement by you, you'd at the very least be mirroring all of your twitter posts here on nostr (or somewhere that they cannot be censored or interfered with). You have a large following on Twitter and most of those people are not here on nostr. Clearly what's more important to you than freedom from interference is reaching your audience. Which is understandable. It's a chicken / egg thing and you are the chicken. Lay eggs here.
#nevent1q…xjdc
There is a new version now (0.7.1) both at Github and also in the WP plugin repository. You can install nostrtium from the WordPress repo like any other plugin. Please let me know what you find. Maybe post an issue on github (https://github.com/pjv/nostrtium/issues).
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. Nullam sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien. Nam consectetuer. Sed aliquam, nunc eget …
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. Nullam sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien. Nam consectetuer. Sed aliquam, nunc eget …
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. Nullam sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien. Nam consectetuer. Sed aliquam, nunc eget …
http://breadtopia.wp.docker.localhost/test-6/
http://breadtopia.wp.docker.localhost/test-5/
Also try deactivating and reactivating the plugin
Try deleting and re-entering your private key on the settings page.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. Nullam sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien. Nam consectetuer. Sed aliquam, nunc eget …
/test-4/
I run Amethyst with no issues on a Pixel 6a under graphene OS.
New beta release (0.7.0-beta.1) available from github here: https://github.com/pjv/nostrtium/releases
If you can, please test version 0.7.0-beta.1 from the [releases page](https://github.com/pjv/nostrtium/releases) on github.
There are new auto-publish options on the settings page.
Note that after updating the plugin (just this one time) you will need to re-enter your private key on the settings page.
FYI, for compliance with the WordPress plugin repo naming policy, the name of the project and location of the github repo have both changed. The plugin is now called nostrtium and the GH repo is at https://github.com/pjv/nostrtium.
At the moment I am alpha testing a new version that lets you set up auto-publishing to nostr for any newly published WP posts. You can choose to post (to nostr) either the WP post excerpt, the WP post permalink, or both together. I'll have a beta version available on github as soon as I can figure out how to build a github workflow to publish a beta to github without deploying to WordPress.
Development is currently glacial due to IRL pressure.
http://breadtopia.wp.docker.localhost/test-3/
This is a test post. Just checking to see whether it ends up on nostr or not.
Nothing to see here, move along. 😉
http://breadtopia.wp.docker.localhost/test-post/
It has to be some kind of bureaucrat-mandated, faux-security concept like making people periodically rotate passwords to ensure they will write them down on a post-it stuck to their monitor.
Yup, that's on my to-do list.
I turned on orbot and did NOT configure it to run in VPN mode and then I configured amethyst to use tor (on port 9050 which orbot is bound to by default) and it's working perfectly. None of the other traffic on my phone is going through tor.
Any app that is proxy-aware could send its traffic to port 9050 to use tor without the rest of the traffic on the phone using tor.
@npub1gcx…nj5z thanks for making Amethyst usable over tor - that's a great feature.
If I understand it correctly, at the moment @npub1gcx…nj5z is running a single server that is scanning a lot of relays and then pushing to FCM.
Would be better, I think, if it didn't even try to count followers.
Personally, I use https://unifiedpush.org/ via https://github.com/binwiederhier/ntfy app on my phone which lets you receive and distribute push notifications to any app that speaks unified push. Dev-friendly intro for Android here: https://unifiedpush.org/developers/android/.
I run my own self-hosted ntfy server, but people who don't want to do that but prefer to support a really nice OSS project than to bend over for Google can use ntfy pro for a small monthly fee: https://ntfy.sh/app
@npub1gcx…nj5z are you building this on top of GCM push?
Sorry i meant a full fence, not just compile time.
I'm sure you are right about just using sled instead of doing my own mmap. But I feel pride that it seems to work so I'm gonna leave that code for a while. Once it bites me, I'll do what you suggest. I've got a compiler fence so it doesn't reorder the writes, but I had forgotten to put in the msyncs!
I'd love to see someone explain how there are so many dots on that visualization and I never got an invite despite my having given them my email address within hours of their initially posting the invite form on their website.
Oy. my non-debug-compiled ./target folder is 4.1GB. I guess rust is doing a bunch of caching to make the build faster. It is pretty damn fast. A lot of cached stuff for a 20MB binary.
In my perfect gossip world, I'd be able to "pin" threads for both @npub1acg…p35c and #SocialMedia (and any other arbitrary filter) at the top of the window and easily switch between them with a click.
Both nostr and Bluesky are fundamentally trying to work on the same problem. The important distinction between what nostr is doing and what Bluesky is doing hinges on whether the respective developers want people whose speech they disagree with to be able to use what they are building to communicate with the rest of the world or not.
In nostr this is clear - the whole thing is architected in a way that it's impossible to stop people from using the protocol to say whatever they want to say. In Bluesky this seems ambiguous at best.
> but it reminds me of Java and XML (no offense intended).
That provoked an authentic LOL. I couldn't think of more offensive comparisons for a software development project than Java and XML.
errrr... maybe I'm missing something obvious somewhere but it looks to me like when a client requests stuff from a relay they are not sending a pubkey, right? In nip-01 the REQ doesn't include sending a pubkey. So without doing some kind of AUTH and/or changing the content of the REQs, for reads how could the relay distinguish between whitelisted people and everybody else?
Very cool. Thanks for the explanations.
On the separate mmap, I'm writing the serialized OpaqueEvent first, then writing the indexes. On a crash we might have a useless event that didn't get indexed, but it wouldn't be corrupt. The writer locks a write-lock, appends, then updates the 'end' pointer at the beginning of the map, then releases the write lock.
Also, these events are opaque (customer-ready, pre-validated). I never access the fields.
I noticed strfry does an index scan of these flatbuffers (of stripped down events) when necessary, using the fields to filter. I'm instead trying to use multiple btree-like indexes:
id -> offset
(created_at, id) -> offset
(pubkey, created_at, id) -> offset
(event_kind, created_at, id) -> offset
(tagdata, created_at, id) -> offset
Each key has to be unique per event, hence the id on each. And the created_at is to scan a since/until range. It's a lot of data to store, but I think that is okay on a personal relay. I don't think it would cause more page faults and cache misses.
I'm finding the set of events that match the filter by doing a functional intersection over the results from these filters. I say functional because I don't collect each result into a set and then intersect them, I intersect as I go: first index: collect the offsets in a hashset; second index: check each in the previous hashset and if it exists, copy to the next hashset (thus functionally being a set intersection) otherwise drop it.
Maybe this is a dumb algorithm. Databases are more my brother's thing, but I'm stubbernly trying to reinvent them myself (I would never learn as well otherwise).
I think deleted events will just be marked as such in another hash table, and a periodic rewrite will filter them out. I haven't really worked that out and now that I'm thinking about it, it could be quite expensive.
A lot of these OS level features like sendfile() or pwritev() become very difficult to use when relying on an upstream library that doesn't expose it's API in a way to utilize those. If I use tungstenite for websockets, I don't think I can write into it's outbound buffers at a low level.
At this point I'm really still exploring. It will change.
The ruleset I desire is (no AUTH requried):
READ:
* Allow whitelisted people to read everything
* Allow everybody to read events by whitelisted people
* Allow everybody to read all 10002 events
* Deny the rest
WRITE:
* Allow whitelisted people to write anything
* Allow everybody to write events where a whitelisted person is tagged [they won't be able to read them back, and that is very important]
* Allow everybody to write any 10002 event
* Deny the rest
I started work on a relay that uses similar ideas to yours but it is very early days. Events are appended to a mmapped file where readers are not blocked during writes (except during resize). Indices use concurrent lock-free kv system optimized for SSDs (rust package "sled") whose interface is like a BTree map between two binary blobs. I'm keying them with things like (pubkey,created_at) pairs so that I can handle since/until quickly. The value is just the offset in the mmapped events file. I'm using a form of serialization (called "speedy") that (at least in rust) performs faster than flatmaps (that may not count when switching languages). Incoming events go through slower processing to canonicalize their encoding and validate their ID and signature. Outgoing reads should be pretty close to as-fast-as-possible. All asynchronous to keep all the cores busy whenever there is work to be done.
I think @npub1acg…p35c has already embarked down the rabbit hole of building his own personal relay, but to circle back, I think what would fulfill the original request would be a way to limit public (un-authed) event reads to only those events authored by white-listed pubkeys.
And then, yeah, there would have to be a way for the white-listed pubkeys to be able to auth on the relay and be able to subscribe to (read) all events, including those written by non-white-listed pubkeys (who are allowed [by my write policy plugin anyway] to write events that include white-listed pubkeys in the event tags).
I use VSCodium. I like it.
If you widen your view and think about it a little bit, the fact that government actions seem to be validating that most cynical possible view has a few implications that go beyond communication privacy.
This is a test post
https://example.com/this-is-a-test/
... and the world would be a better place.
#note1w8p…gu25
I don't have any C++ fu, so I have not spent any real time spelunking the core source code, but I know that its db is LMDB. My only hands-on experience with strfry is from the devops side; getting it running in a container, and writing the python write policy plugin in my repo.
That strfry exposes a stdin / stdout interface to any other process that can effectively pipe input and output is brilliant. It opens up so many possibilities. @npub108p…yev6 has written a bunch of different write policy plugins including iirc some that are storing and referencing state. Maybe I can think of a way to write some spam filtration for overzealous taggers. Or maybe if I keep tagging @npub1yxp…qud4 in this thread he'll come in with something interesting, though I am guessing by the number of commits in the strfry repo lately that he must be pretty busy with other stuff.
Yeah I don't want people tagging me as a way to store data on my relay. That could get very spammy very fast once people learn they can abuse that.
If it was a database I would conditionally add a WHERE clause for readers when not in the whitelist, but I think strfry is more manual and not SQL right?
That's true - it does serve all events But since it only allows writing events from keys you've white-listed, events that tag the whitelisted keys, and kind 10002 events, there's not much else for it to serve. Is the concern that it serves events from others that tag you?
Maybe we can get @npub1yxp…qud4 to add read policy plugins to strfry to mirror the write policy plugins though I could imagine that having some performance implications.
No, I thought it still served all events rather than only allowing people to pull your events.
Mike, did you try my docker server with the write policy plugin? If so, what didn't work for you? Tag spam?
Welcome. Love to see you post here instead of yet another platform that will, must inevitably, bow to the pressures.
wrote this to a twitter friend about a month ago...
==============================
this next period - year or two or three - is going to be interesting. I think that either bluesky or nostr is going to win the decentralized internet. Bluesky has a far better thought-out technical model, but the way they are developing it (which may well be required in order to have such a tight model) is totally choking any real energy which is absolutely necessary to get people to care.
nostr on the other hand is total chaotic wild west. It has massive juice in the developer community and a tribally passionate userbase is building daily. But there are so many fundamental scalability problems with the protocol that it really seems likely (to me) that at some point it will hit a threshold number of users and the whole thing will fall apart and the only way to make it work then will be to tear it all apart and sort of start over from scratch with fundamental changes. Which may or may not kill all that positive energy.
if the bluesky people are smart enough, they will soon throw the doors wide open and allow the same kind of wild west atmosphere to happen with their protocol that is currently happening with nostr. It would start a total war (in a good way) because the nostr people are totally tribal. I'm sure they will very soon start calling bluesky a "shitcoin". but i don't know if the bluesky team are going to be willing to let go of what they created, and if they try to hold on to it, they will never have a prayer of catching up to the energy in nostr.
the infamous ouroboros directory.
Sorry, I think Amethyst is great work but I think everything in this note is wrong.
Reports are bad.
Relays introspecting content is bad.
Play store and Apple store are bad.
Play Store and Apple store policies are bad.
Complying with bad policies is bad.
Changing the world for the better means breaking away from the old, bad stuff and charting a new course.
#nevent1q…lmq5
I don't think there is anything inherently wrong with reactions or tallies of reactions. I think they can be meaningful and useful in many contexts. They just are not meaningful or useful (or truthful / accurate) in this particular context.
I think - and am pretty sure - the world would be a better place if people stopped believing in lies - including the lies that make them feel good. As I've argued here: https://github.com/nostr-protocol/nips/issues/159#issuecomment-1407384311 in a meaningfully decentralized system like nostr, there is no practical way for either clients or relays to actually count actual reactions. So that means that the tally next to the icon is necessarily fake news. And what is the reaction itself without the tally? 100% meaningless. It's a lie.
Of course people are going to do whatever they want and nostr is what it is exactly because people can do whatever they want with it. It's just too bad that what so many people want to do with it is to directly ape - without any discrimination - everything that legacy social media platforms do. Because a lot of what they do is bad. It would be better if nostr filtered out the bad stuff. It would be better if instead of re-creating legacy social media platforms, nostr created something entirely new that replaced legacy SM because it's better, not because it's the same.
In that issues thread that I linked to above @gkbrk made a comment about a way to make reactions useful in the context we're discussing. If there were a performant and practical way for me to see that PEOPLE I FOLLOW had a reaction to a given event, that would be really useful. This would be the job of a smart client (definitely not a relay thing and that’s a good thing - clients should be smart and relays should be dumb).
Agree with both of these sentences.
Gossip will have a "Relays > Sign-Up" page with links to the payment pages of relays that supply them in their NIP-11 along with pricing detail. It will not offer any hard coded relays, it will simply discover them as it currently does, requiring the gossip user to kick start the process when they first set it up. For relays that don't supply this information, they won't be getting this "free advertising" via the gossip client... I think that alone may incentivize relays to fill in those fields.
Also @npub1acg…p35c, it might be good to allow gossip users to override the default POW settings on a relay-by-relay basis. Or maybe not even need to do that manually but just have a general setting to automatically do whatever POW that a relay requires in `limitations.min_pow_difficulty`.
I've been noticing for a while that there doesn't seem to be a clearcut (interoperable) way to determine whether a given relay requires payment to post there or not. If you do a lot of manual digging and searching you can figure it out on a relay-by-relay basis but that seems unacceptable from a UI/UX point of view unless we (devs) want nostr to be geek-only.
I think for this issue what's probably needed is some kind of push to make both relays and clients really fully implement the "Server Limitations" (at least), and also the "pay-to-relay" blocks from the "extra fields" in NIP-11. So relays need to return those fields and clients need to parse those fields and if the relay has `limitations.payment_required: true` then clients should display that somehow so that it's easy for a user to know whether they can post to a relay right off or whether they need to do something special first (pay, configure POW, etc).
Too early for this now, but it would also be great somewhere down the road if there were a NIP that standardized how to pay for pay-to-post relays in a way that it could be implemented within clients such that users could do it all from within their client with a click or two. In my perfect world, this payment would not be limited to bitcoin / satoshis, but would instead be completely agnostic so that relays could take payment however they want and users could choose from among whatever choices the relay offered.
Everyone using f-droid should switch to obtanium.
"Obtainium allows you to install and update Open-Source Apps directly from their releases pages, and receive notifications when new releases are made available."
https://github.com/ImranR98/Obtainium
Nice.
Complementary personal relay server setup which also supports the gossip model: https://github.com/pjv/strfry_personal_docker
From the readme:
MOTIVATION
I think that in order for nostr to be what it can be, there needs to be a LOT of small relays all over everywhere as opposed to a short list of giant, "popular" relays that everyone uses which then must inevitably become centralized points of all manner of vulnerabilities that nostr is explicitly about avoiding.
Mike Dilger, author of the nostr client gossip as well as NIP-65 wrote The Gossip Model -- a description of how gossip manages relays in a way that can support this vision of having many smaller relays all over the place and still let people find the content they want to follow via nostr. In that document there is a section called Personal Relays. The write policy in this repo is a first stab at implementing personal relays in that fashion.
This note is a test of "double quotes"
And also of emojis 🍕.
And uñicodes.
And fake's apostrophes.
But what happens if there is a \ back\slash in the text?
That's an interesting experiment.
Um. Wow; it's not that often that something lands me right exactly on the fence where my crotch feels so uncomfortable (also wondering if this post gets moderated by chatGPT because I wrote "crotch").
On the one hand... this is a clever use of an interesting tool to address a real issue.
On the other hand... (hard to nutshell the other hand because it's a long, giant rant) this is a textbook contribution to what I'm calling "the great dumbing down" where ubiquitous use of LLM AI's to moderate human speech has the highly negative systemic effect of making AI seem "smart" only by comparison with the monsterous level of stupidity in a human discourse that is constrained by the boundaries of LLM AI competence.
I guess I'm coming down on the disfavor side of the fence because I think that the great dumbing down is ACTUALLY the biggest threat of AI (as opposed to the science fiction story that recent letter-writers are concerned with) and I also think that the better way forward for social media users to not get their eyeballs stained with garbage is to not look at open sewage pipes (global feeds on public relays in nosterese) and instead evolve a working WOT model where you have interesting follows and you can also easily tap into the content of their follows and their follows follows (out to some user-configurable limit of degrees of Kevin Bacon).
Cool! I am definitely going to check that out this weekend.
I published a repo that implements a usable first stab at the personal relay you described in your "Gossip Model" page on your website.
It's docker based and lets anyone who can spin up a vanilla linux VPS have a strfry-based personal nostr relay up and running in about 10 minutes.
The repo is here: https://github.com/pjv/strfry_personal_docker
#[0]
This note is a test of "double quotes"
And also of emojis 🍕.
And uñicodes.
And fake's apostrophes.
But what happens if there is a \ back\slash in the text?
This note is a test of "double quotes"
And also of emojis 🍕.
And uñicodes.
And fake's apostrophes.
But what happens if there is a \\ back\\slash in the text?
This note is a test of "double quotes"
And also of emojis 🍕.
And uñicodes.
And fake's apostrophes.
But what happens if there is a \\ back\\slash in the text?
This note is a test of "double quotes"
And also of emojis 🍕.
And uñicodes.
And fake's apostrophes.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. "Nullam" sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi commodo, ipsum sed pharetra gravida, orci magna rhoncus neque, id pulvinar odio lorem non turpis. \"Nullam\" sit amet enim. Suspendisse id velit vitae ligula volutpat condimentum. Aliquam erat volutpat. Sed quis velit. Nulla facilisi. Nulla libero. Vivamus pharetra posuere sapien.
This note is a test of "double quotes".
I'm building a WordPress plugin that is a small nostr client that allows sending WordPress content to Nostr from within the WP post editor. First public release on Github: https://github.com/pjv/wp-nostr.
#[0]
#[1]
This 100% whole grain bread has a light maple sweetness along with tasty oat and wheat flavors and the rich complexity of natural sourdough leavening.
https://breadtopia.com/maple-oat-and-wheat-sourdough-bread/
Also rocketchat which I deployed instead of zulip when I evaluated them both, but if I had it to do over again now without the friction of user lock-in, I'd probably go with Matrix.
Chilean marraquetas are crusty on the outside and soft and tender on the inside. They are shaped into four segments, so you might eat half with the traditional filling of mashed avocado and a pinch of salt. Later in the day, the other half will call out to be enjoyed with cheese and quince jelly alongside a hot cup of tea. Finally at dinnertime, choripán, a grilled sausage sandwich perhaps with Argentinian chimichurri, may start to look really appetizing. Suddenly you’ve had marraquetas at every meal!
https://breadtopia.com/chilean-marraquetas-sourdough-or-yeast/
This note is a test of emojis 🍕.
This note is a test of uñicodes.
This apple crisp takes advantage of flavorful whole spelt and oat grains. The apple base is tart and delicious, and the streusel topping has a lovely contrasting texture, plus extra fiber, nutrients, and nutty flavor.
https://breadtopia.com/spelt-and-oat-apple-crisp/
Pizza is a savory pie for celebrating pi day. Happy #piday #pizzalovers. This pie uses Breadtopia's stone-milled whole grain all purpose flour made from hard red winter wheat berries.
https://breadtopia.com/whole-grain-sourdough-pizza/
#[0] I have not tried this on a linux box (I use a mac), but I think you might be able to easily build for macos using cargo-bundle: https://github.com/burtonageo/cargo-bundle
I'm compiling gossip from the repo, but early on out of curiosity I installed cargo-bundle, created a simple Cargo.toml and then was able to generate a stand-alone app bundle for macos that worked fine.
cargo-bundle says it cross-compiles with a simple --target flag so my guess is that you would be able to pretty simply build at least for intel macs. On a quick glance through the repo I'm not sure if it can cross-compile for apple silicon yet. There's an open issue about implementing fat binaries that would run on both intel and apple silicon macs.
If you want to try it, I'll test for you. I have both an intel mac and an apple silicon mac.
Actually in this case seems more like the evil of banality.
Here's a personal relay strfry write policy in python: https://github.com/pjv/strfry-python-write-policy
Never mind; I found your post that explained what happened and re-set my follows and see their posts again.
#[0]
#[0] If I'm no longer seeing posts from my fediverse follows through the relay.mostr.pub bridge (were working initially, then stopped without changing any of my configuration in my clients), how can I try to debug this?
It's not the diets, it's the humans. Every crypto currency is a religion. Every political leaning is a religion. Every technology for communicating with other humans is a religion. Every sports team. Every music group. Every media star. Every billionaire...
No, strfry and the plugin(s) simply communicate via stdio. The plugin is an executable in any language that can deal with input on stdin and write output to stdout. I wrote mine in python.
Here's the brief documentation: https://github.com/hoytech/strfry/blob/beta/docs/plugins.md
I don't think that strfry currently exposes enough through its plugin framework to implement the anti-spam ideas here (which I agree will be essential). Or if it does, it's currently undocumented.
What it does is let you build a simple (non-stateful) "write policy" plugin that gives you the incoming event (with some metadata like IP address, etc) and lets your plugin decide whether that event should be accepted or not.
The plugin I am currently testing on my instance:
1. lets you define a whitelist of pubkeys that are allowed to post anything.
2. lets anyone post a kind 10002 event
3. lets anyone post any event with a 'p' tag that includes any of the pubkeys in the whitelist
4. rejects writing everything else
strfry seems not to have any "read policy" plugin implementation (yet?). So I am unable to put limits on what people can read.
Or maybe even scraping is too expensive. I can totally live without twitter.
I agree with your assessment. Until and unless twitter provides a reasonable API you shouldn't try to display the cards.
What about scraping the content of the tweet and rendering it sort of like a quoted post? (Maybe that's what you already do - I don't remember and couldn't find any examples of tweet quoting posts in my current timeline).
#[0] great document.
I'm working on a write-policy plugin for strfry that will implement most of what you specified in the section on personal relays. Can you expand some of the details of what constitutes "events tagging me"?
Does that include scanning the content of notes for npubs and / or hex pubkeys? Or just looking at 'p' tags?
Any subset of event kinds you have in mind for "events tagging me"?
Great refinements. Gossip getting more usable every day.
The way gossip actually works, you get both intelligent relay discovery and also the ability to manually configure relays.
As an experiment, I bought a pixel 6a and installed grapheneOS on it and after some monkeying around for a few weeks I am now having the best "phone" experience I've ever had (including iPhones in the past).
The two best parts:
1. The phone is de-Googled by default and it was easy for me to make it work for my purposes without it ever making a network connection to Google without my knowingly making that connection.
2. I have so much more control over what I have installed and how it is configured that I've been able to make the phone work largely the way I want it to work. Not the way Google or Samsung or Apple want it to work. It's like a linux box where you can set it up your own way if you have the skills.
Both of these things are probably pretty specific to my use-case and may not be as do-able for other people. But for me Graphene has resulted in my not feeling bitter about picking up the phone for the first time in years.
An excellent alternative to fdroid is obtanium https://github.com/ImranR98/Obtainium which is an app you install on Android that lets you then keep track of releases and updates of APKs directly from their own repos. I use it to keep Amethyst up to date directly from the github repo.
Given the current set of incentives in the protocol, it seems like this is the only possible outcome. Anything that makes relays not interchangeable has to end up this way, right?
If relays were like Internet routing hardware where nobody even knew which relay they were connected to (who knows which brand of BGP router their traffic flows through?) then using some kind of refined version of the gossip protocol could (maybe?) be able to spread the load.
Unless people are ONLY going to use nostr to create little private silos (which is a perfectly fine limited use-case), I think "global" (public commons) nostr is going to have to move in the direction of clients only showing you content from people you specifically follow and then optionally (WOT-style) also people your follows follow.
If relays have to try to "block" stuff (as opposed to just not sending stuff that clients aren't specifically requesting), then: A. nostr won't be able to scale and B. nostr will eventually have to become twitter (or mastodon).
Nobody should be looking at so-called "global feeds" (except in private nostr-driven silos). The global feed of "global" (public commons) nostr is like a high-bandwidth fiber cable with TCP/IP traffic on the Internet. That's something that carries what you are interested in along with a vast sea of what should seem to you to be garbage you are not interested in. Why would anyone want to try to look at all that garbage?
I run on macOS, compiling from source. It's pretty simple. You might actually be able to build macOS packages on Linux if you want to with https://github.com/burtonageo/cargo-bundle -- i didn't try it on a linux box yet but on my mac all i had to do to build a binary was create a very simple Cargo.toml file and then issue a command and it built an executable mac bundle. Since gossip is totally self-contained maybe you could cross-compile / bundle for macOS - at least intel mac hardware.
And that's in a context where you can ACTUALLY count followers. You can't actually count followers for real in nostr.
If nostr becomes what it could be, looking at so-called "global feeds" would literally be something like looking at TCP/IP traffic on global Internet routing pipelines with wireshark. That traffic should not be remotely interesting to most normal people most of the time.
Should gossip also be fetching metadata for npub mentions within the text of notes? As far as I can tell it currently doesn't - if the npub metadata has already been fetched gossip renders a NIP-05 name but if it has not, it renders a truncated npub as a link. i guess you'd want to limit how many of these you did so if someone posted a note with a thousand npubs it wouldn't DDOS you, but in the case where there is just a few mentions i think it would be a good addition.
This seems to be working great. Excellent refinement.
LOL, I @-ed mikedilger in a reply to the other mikedilger (sorry didn't realize that was you, Mike).
Thanks! Still wondering if note text could be selectable. #[0]
Question: should I be able to select and copy that text from the note in gossip (I cannot)?
I was also freaked out when I recently read that at least one splashily public mobile client is completely not verifying signatures by default. I can understand alpha testing in that mode with plenty of DISCLAIMERS everywhere, but in my mind, signature verification is so completely and totally fundamental to the nostr protocol that i don't see how you can call it nostr with a straight face if your're not verifying signatures by default. I don't think it's correct to even have an option to not verify them.
Personally, I don't see how anyone can release a public version of a client that isn't verifying signatures on every note that the user sees (but not every note! - see below).
Which brings me to the question of parsimony. Years ago when I was messing with scuttlebutt I was disturbed by the amount of "waste" overhead that the whole protocol relied on. It felt to me like everyone who wanted to participate had to download and lug around their own redundant copy of the entire Internet. That made me feel that there was no way SSB could scale beyond toy use but I was looking for something that could topple the platforms.
I've seen @vitor exploring the use of merkle trees or bloom filters as a way of pairing down the amount of events that a client is receiving from a relay. I don't understand enough about either to know if that is a viable approach but it seems like some kind of significant deduplication is needed at the client level. Ideally it could happen in the negotiation between client and relay so it saves bandwidth, but every event includes a globally unique, content-addressable ID and at the very least clients could/should be discarding any event they get from a relay that they already have, right?
In my naive mental model of client data, events are stored in a DB table uniquely indexed by their event.id. So whatever code is inserting new events into that table would first query whether the db already has that id (which should be a relatively instant query) and toss it if so. If not, then verify signature and then insert. Is something like that scenario not workable in practice? Or is this already what all the clients are doing and that level of optimization is still not adequate to make signature verification viable on mobile?
At the very, very, very least, it seems like every client should absolutely verify signatures on any events posted by a users follows.
But maybe this all speaks to how people are using nostr. I personally do not at all get why or how anyone cares about the firehose of "global" feeds. That to me seems like 100% anti-value. Who the hell cares to see (for more than a second out of curiosity) what a mad mixture of bots, spammers, scammers, and people they don't know (or know of) are spewing into the interwebs? That is attention pollution. It's totally toxic. But, whatever, I guess. Maybe I should add a Seinfeldian "not that there's anything wrong with that".
But I can definitely see where mobile clients could optimize on signature verification by not verifying events in global feeds (which are 99% garbage anyway). Every event from a follow should be verified though. Maybe also every event from a follow of a follow too if that doesn't get too expensive. Would that work?
That's a beautiful photo.
Welcome to the great dumbing down. Where "AI" ends up being "intelligence" by making humans so stupid that mechanism seems smart by comparison.
BTW, I don't even see the baby photo post in my timeline - the first post in that thread I see is the one that starts with "This is wild" (https://twitter.com/Snowden/status/1627021515207196672), I had to follow that tweet into the thread to even see what you were talking about.
I like this post (how hard was that?). Instead of sending large integers across the interwebs, I'll pay tribute by adding this:
In addition to all these good points, there's also the fact that unless nostr turns into something that is not nostr (i.e. not meaningfully decentralized) or someone invents magic, there is no way to get accurate aggregate real-time counts of anything (not likes, not followers, not anything). And what are "likes" without counts of likes?
There are many ways that decentralized social media is going to diverge from what people are used to on centralized platforms. As I think you wrote somewhere, part of nostr is embracing the chaos.
For the tags, when I mentioned it, I was thinking of 't' tags on kind 1 events using NIP-12 queries. Is that what you have in mind?
I was thinking that authors tagging posts is the lowest friction way to do what you (as a reader) need them to so you can read about rust but not BTC.
An author's (self-defined) tags could be part of their profile.
An author's (self-defined) tags could be part of their profile.
I also think it would be great for private groups to separately create their own private nostr networks wherever and whenever they want. They would be separate from the wider, global nostr network like a LAN is separate from the interwebs, though using the same plumbing.
I really hope this isn't what the future of nostr looks like. It seems like a re-invention of a web forum.
What I hope nostr becomes is a global public commons; what twitter should have been but failed to be. It should definitely support ways for users to slice, dice, group, filter and make community. But it should also allow for an un-siloed connectivity between anyone and anyone and/or anyone and everyone.
I agree and I like this best because it keeps all the smarts in the clients and keeps the relays more agnostic.
Who knows how this will all evolve and what it will evoke from users in the future. I just have a feeling that configuring separate sets of relays for each different type of content that you want to post is going to feel cumbersome for most users. It feels cumbersome to me and I'm a geek. I think 1 might be the simplest / easiest solution but it limits you in ways that some people probably wouldn't like. I would certainly do that for some purposes, but I probably also want to be able to post as "me" about various topics without being someone else.
I think even my idea (3) is going to feel cumbersome to a lot of people who just want to type into a box and hit send. But I also think if the UI is simple enough and there is some peer pressure from followers it could fly.
But I also think this whole topic really depends a lot on the vision you have of nostr as a network going forward. My preferred vision has a big, interoperable fabric where organic "communities" might evolve based on follow lists (and probably follow of follow, etc. lists), but there are no hard and fast silos as could be implied with more purpose-driven relays as in 2 and your original post that made me think about usenet.
tags on notes and you follow not ust a user but a user plus some (sub)set of their tags?
This is why nostr relays have to be simple and commodifiable and plentiful and any one of them needs to be painlessly and instantly replaceable by another. As soon as there is one relay that holds more weight than others (is more popular, has to be used by everyone in order to be able to follow each other, etc.) then nostr eventually devolves to mastodon.
Simple, commodifiable, interchangeable relays. That's the ticket.
Vitor, do take a look at unifiedpush (https://unifiedpush.org/). It's a very developer friendly, cross platform framework that lets you do decentralized push notifications outside of the grasp of tech titans. It has zero dependence on FCM or Apple services. It works amazingly well on Android with ntfy (https://github.com/binwiederhier/ntfy-android) which can be either hosted or self-hosted.
Here's a simple android unifiedpush integration example in their github: https://github.com/UnifiedPush/android-example
if i liked likes, I'd give you a like. animated anything when you are trying to read is stupid as fuck.
Yes, seems to be fixed on that commit. Thanks.
unified push is dev-friendly, cross-platform, awesome non-FCM push notifications. Sample android app integration on their github here: https://github.com/UnifiedPush/android-example
Crash happened when trying to reply to an event. Here's the stack trace (though guessing it's not super usable, or if it is, count me happily not a rust developer):
thread '<unnamed>' panicked at 'index out of bounds: the len is 0 but the index is 18446744073709551615', src/db/person_relay.rs:339:17
stack backtrace:
0: 0x10cdd1922 - __mh_execute_header
1: 0x10cdef2aa - __mh_execute_header
2: 0x10cdcb76c - __mh_execute_header
3: 0x10cdd16ea - __mh_execute_header
4: 0x10cdd2fd6 - __mh_execute_header
5: 0x10cdd2d27 - __mh_execute_header
6: 0x10cdd371d - __mh_execute_header
7: 0x10cdd34d3 - __mh_execute_header
8: 0x10cdd1db8 - __mh_execute_header
9: 0x10cdd319d - __mh_execute_header
10: 0x10ce34693 - __mh_execute_header
11: 0x10ce347d6 - __mh_execute_header
12: 0x10c4bb1d1 - __mh_execute_header
13: 0x10c50866d - __mh_execute_header
14: 0x10c4f53e6 - __mh_execute_header
15: 0x10c4c490a - __mh_execute_header
16: 0x10c3edc10 - __mh_execute_header
17: 0x10c46c13d - __mh_execute_header
18: 0x10c492380 - __mh_execute_header
19: 0x10c44a6f2 - __mh_execute_header
20: 0x10cdd5f07 - __mh_execute_header
21: 0x7ff8168404e1 - __pthread_start
Got this crash with 27121f4:
thread '<unnamed>' panicked at 'index out of bounds: the len is 0 but the index is 18446744073709551615', src/db/person_relay.rs:339:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
(I'll set up that env var and see if I can repro)
I'm also on graphene. I do have Google Play Services installed in the profile where I am using Amethyst but none of the google apps, frameworks, components have any network permissions so they will never be able to make any translation stuff available to Amethyst. I am not getting any crashes with recent versions of Amethyst (I stay up to date with github APK releases).
My plea is just to keep it like this in the future. Translation is a nice-to-have for me but for my purposes, it's way more important to not have Google in my life than to be able to read non-English notes.
Please just don't make the ability to DL translation data through Google a hard dependency for the app. Just let the whole translation machinery fail silently and gracefully (as I think it does now) if someone or other happens to be running Amethyst on a de-googled device.
Also, Amethyst is great.
Agree. Clients should get smarter and relays should stay as shitty as possible and be exceedingly plentiful. Nostr is the six dregrees of Kevin Bacon revolution.
https://github.com/nostr-protocol/nostr/pull/111#issuecomment-1412733305