Try deleting and re-entering your private key on the settings page.
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.
Nominating nostr:npub1pjvcwasj9ydasx9nmkf09pftsg640vm5fs7tzprssew8544yj2ds6e0h42 for this project. We build out content brands using WordPress, creating news driven audiences based on niche verticals and we need a plugin to help us grow and, naturally, to help us #grownostr beyond the BTC community. This is the best solution available afaik but it needs some new features. Please take a look 👀♥️💪👇
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.
11
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.
nostr:npub1pjvcwasj9ydasx9nmkf09pftsg640vm5fs7tzprssew8544yj2ds6e0h42 thank you for making the Nostrtium plugin for wp to nostr! Wanted to ask if there is a simple way to enable an "auto-post" feature so that my wordpress posts automatically push to nostr on publish or maybe using a cron?
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.
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z thanks for making Amethyst usable over tor - that's a great feature.
If I understand it correctly, at the moment nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z 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
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z are you building this on top of GCM push?
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 nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c 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.
So #[0] posted a blog post about bluesky that ruffled some feathers: https://fiatjaf.com/ab1127fb.html
This triggered a long skeet stream reply from bluesky developer Paul Frazee: https://staging.bsky.app/profile/pfrazee.com/post/3jv72j3fp6g2r
This then caused me to write up some thoughts:
The world of decentralized protocols is gaining momentum, and it's exciting to see projects like Nostr and Bluesky at the forefront. Many of us have dedicated years to developing these protocols, and now they're capturing global interest. I've been tracking various decentralized social media protocols for a long time, and if you're interested, you can find my comprehensive database of open social media protocol projects here: https://airtable.com/shri7e7EHoTi0cEjO
Nostr, at_protocol, and other projects take inspiration from Secure Scuttlebutt, which I had the pleasure of working on alongside talented individuals like @pfrazee and @jay. Nostr is a slightly modified version of Scuttlebutt, while at_protocol represents a more significant reimagining. At_protocol borrows ideas from the IPFS ecosystem and W3C DID standards, while Nostr incorporates concepts from Bitcoin technology (not a blockchain or cryptocurrency project). Both projects have received substantial support from #[1] , who funds them but doesn't control their direction.
Nostr began as a humble side project, growing organically as developers adopted it. In contrast, Bluesky started with significant press and a high-profile search for a team lead, taking years to evolve from an idea to a funded project. Bluesky's community experienced challenges that led to a split, and the original community renamed itself https://dsocialcommons.org/. Nostr, on the other hand, never encountered such issues, with developers contributing to the project independently.
The two projects represent different approaches to open source development: the cathedral model (Bluesky) and the bazaar model (Nostr). Both have seen success, but I must express my disappointment with Bluesky's choice to follow the cathedral model. Despite my frustration, I have great admiration for the team behind Bluesky and the work they're doing. However, Bluesky employees maintain full control over the at_protocol, leaving little room for external contributors.
In contrast, Nostr provides an open platform for contributions, enabling me to create an app (nos.social) and write specifications that are openly debated: https://github.com/nostr-protocol/nips/pull/457. Bluesky's code is indeed open source, but their development process is not. This is reminiscent of how Safari's WebKit or Android operate as open source projects without truly embracing the open source development methodology.
Recently, I expressed concerns about Bluesky as it currently operates as a single unified network. Friends advised me to take a step back and give the team time. I experimented with their Indigo PDS server and found it promising. I believe that the at_protocol will eventually become an open, multi-server protocol. The people behind Bluesky have a long history of working on open protocols and are not developing this technology to create a new, closed ecosystem.
On a personal note, I feel a stronger social connection to Bluesky's early adopter community but appreciate Nostr's openness for contributions. I could potentially create an at_protocol client, but making substantial contributions to the Bluesky protocol seems reserved for employees and select advisors. Therefore, I choose to invest my time and effort in open projects. I firmly believe in Conway's law, which states that the structure of the organization building a technology will shape the technology itself.
I believe @fiatjaf might be overly critical of Bluesky. He had the luxury of working in obscurity without the pressure of media attention while figuring things out. In contrast, Bluesky faces high expectations and the responsibility to "replace Twitter." The stress that the Bluesky team endures while trying to develop their project under the watchful eyes of many likely contributed to their adoption of the cathedral model of open source. I empathize with the challenges they face in this environment.
Much of the internet was built using the bazaar model, consisting of small pieces loosely joined. This approach gave us the web and numerous other systems we use today. Bluesky's design-driven model is more meticulously architected, but it reminds me of Java and XML (no offense intended).
I believe that these networks can interoperate. I already communicate between the fediverse and Nostr daily, and while it's not perfect, it mostly works. I'm optimistic that we'll achieve similar interoperability with at_protocol once the system becomes more open. It is essential to recognize the strengths and weaknesses of both approaches and to appreciate the incredible work and progress made in both projects. As the world of decentralized protocols continues to grow, I remain hopeful for a future that embraces collaboration and openness.
> 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?