If that doesn't work, try Coracle:
Discussion
yeah, habla didn't work for me, i'm not sure what relay hints that naddr link uses, maybe something to do with that
We will #thoon not need to use any app, other than #Alexandria, for normal stuff, and I am so there for that. 😂
I just can't. I'm so done. It's so over.
i'm sure once the feature set is sufficient we will see a lot of users, then maybe we can look at how to monetise it, maybe to do with relay subscriptions
also, if we can get in the face of the commie grant orgs donors they will start to wonder how well their money is being spent and then we just need a formal corporate structure to do the pay for the performing devs :)
i can say that i would take a pay cut to be able to walk away from the silly shitcoin-oriented work
I legit ♥️ my day job, but #GitCitadel is increasingly crowding it out. Need to go get some testing done. Bye, for now!
Well, theforest is the core relay it'll use (in addition to the mailboxes), and that's a paid relay.
Wait. I am confused. Is Alexandria morphing into something different?
Like a client you could use for every day use on Nostr as well as the original projects intentions?
We've always wanted to be an enterprise solution, with a community feed and social interactions. It just wasn't planned to be part of the first release. We've been pulling stuff forward.
the appalling state of nostr kind 1 clients is kinda forcing the issue
Yeah, I legit can't work like this. I need a full-featured web client that actually functions, to get my work done.
Why web?
1) Because it's going to be Alexandria. Already 1/2 done.
2) Because it's the viewer for my CLI, and I therefore use it from my Linux laptop.
3) No point making a desktop app, as our other app (#GitRepublic) is going to be Linux.
4) Because I am not going to write articles on my phone, but with a web app, I could.
5) Because I can off-Nostr share stuff on it with elegant OpenGraph hyperlinks.
6) I hardly use my phone.
Is git republic the name of the git hosting project?
Also if it is for Linux, what will the packaging format be?
Yeah, we're calling our solution for git on Nostr "GitRepublic."
nostr:nprofile1qyt8wumn8ghj7etyv4hzumn0wd68ytnvv9hxgtcpz4mhxue69uhkummnw3ezummcw3ezuer9wchszythwden5te0dehhxarj9emkjmn99uq3uamnwvaz7tmwdaehgu3dwp6kytnhv4kxcmmjv3jhytnwv46z7qgwwaehxw309ahx7uewd3hkctcpzdmhxue69uhk7enxvd5xz6tw9ec82c30qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uq3samnwvaz7tmwdaehgu3wvekhgtnhd9azucnf0ghsqgxwr0u6myskfhez0072k2qnry7xp66qy8f4ha9mh3h6ynzkp58nayqfnfns has already done some of the legwork to figure out how to package and distribute .deb packages, so we'll be using that format.
Ugh you chose the shittiest format with the most bias and dependency hells. You are also severely limiting your overall market reach in the Linux world too.
Try building with flatpaks instead. It is Linux distro agnostic. Easier to ship and maintain all the dependencies. Works on any linux distro and not just the bloated Debian based ones. Post it on flathub.org or run your own flatpak repo
https://docs.flatpak.org/en/latest/first-build.html
Appimages are also an option, but maintaining updates on them are a bit of a bitch.
If you need help. I am willing to go down the rabbit hole of researching and packaging up a flatpak. I would hate to see such an awesome project kneecap itself right out of the gate. By going through .deb packaging and maintaining hell while severly limiting your success potential.
Everyone and their mother uses apt, tho.
once the package creation scripts are made it's not really that bad
and debian is by far the most common base for linux installations, the need for snap and flatpak and appimages has failed to materialise
We also have Nostr-native packing solutions. I'd probably prioritize those, since that's where the beta-testers will be.
You all must be living in a bit of Linux bubble. I try to stay updated on the entire family tree and distrohop to stay apprised on the latest developments.
Flatpaks and snaps are highly used on a daily basis now by the majority of distros when their repositories are out of date, or do not have what they need. Many large companies would now rather package up once and ship everywhere. Than to deal with one Linux distros package management process over the other and miss out on valuable market share opportunities.
Just use logic and reasoning on this one.
Would you rather use flatpaks, appimages, or snaps and be able to have an unlimited audience.
Versus using deb packages, signing up for inevitable dependency hell headaches (guaranteed), and only ever having a medium size audience.
If anything, after deb packaging, I believe we’ll do rpm for the Red Hat and Fedora distros.
Ah. I use that at work, for installations on the testserver.
Ah very well. Your server must be running a Red Hat Linux.
I was wondering why they were using it. That explains it, thanks.
it could be opensuse also, that uses rpm too
iirc, opensuse is a german distro, or at least it's european, debian is american
It is german !
as i understand it, quite widely used by german companies
basically nobody else in the world uses it... it also has a slightly different tool called "zypper" iirc, that does something like apt for deb packages as zypper is for rpm, similarly there is dpkg and then there is rpm
i might be misremembering, i ran opensuse for a little while
i approve of this policy... i avoid using snaps or flatpaks as much as possible because they tend to be bugging, still, with their isolation and being able to access my home directory
Tried to install a flatpak on Saturday, but it was like 15 steps and in the end it didn't work, so I installed something else with apt.
https://distrowatch.com/dwres-mobile.php?resource=family-tree
You are choosing one branch of the Linux family tree over the other. Alienating hundreds of other Linux distros by giving preferential treatment of Debian based ones over the others.
For example when you enter the enterprise landscape you may find that there are more RHEL based distros. Than Debian based ones that are being used.
When you decide to go down the Debian path you have to consider the dependency hell you are signing up for too. When there are major version releases of Debian, or Ubuntu based distros your dependencies will always be out of sync with each other. Debian will always be behind and ubuntu will be ahead. Leaving your users up shits creek to paddle themselves out of the mess.
In the Linux world there is a shift towards a more universal package management approach. With flatpaks, appimages, and snaps being the preferred choice for Linux package management and distribution. This is, because by bundling the dependencies with the application and maintaining them in this method. You do not have to worry about the dependency hell.
With flatpaks you make one package that will work with every Linux distribution. Easily updated and maintained gracefully. You can use debs if you want, but when you ultimately experience the headaches later. Remember there are better more up to date solutions that can better the Linux community as a whole. Not just one biased branch of the family tree that is slowly becoming obsolete.
We’re not limited to any packaging format. We’ll deliver in the most popular and the most practical ones. Like every respectable software foundation out there.
#GitRepublic is an umbrella-term for everything #GitCitadel does involving git. So, the API, a desktop client, the public git server, the website hosting the git server apps, etc.
Gotcha!
Thought you guys were ditching Native suddenly and didn't get why.
Web has so many limitaions for me/us :pointright: why we're building local-first Flutter apps.
We're building something for scientists to edit research papers and form review panels, and for authors to edit the formatting of their books, and stuff. It should work on the phone (and it does), but that isn't the main machine they are going to be using for that.
Yup, my editors will be 3x better on desktop too.
i've got a back-burner project to build out an adequate widget toolkit for the gio golang native and it can do one codebase for all platforms including web
i finally got fed up with how they had continued to keep important, and occasionally changing parts of the widget toolkit inside an internal (unable to be accessed from a separate project) and i wrote a little web script with sed to rename all of the internal folders and it allows me to maintain parity with their codebase without its limitations
so, it's coming also... i've been wanting to make a legit instant messaging protocol like IRC using nostr relays, complete with nickserv and chanserv and an ephemeral-first focused messaging scheme (the chanserv caches messages, and the nickserv controls access)
Keep us posted sir :salute:
It's not just kind 01. I got desperate and added 30818s (wiki) to the reading view, and now I'm going to add kind 30023 (long-form) to the social feed, so that I can post articles by linking to Alexandria, instead of habla or highlighter or whatever isn't working today.
Njump usually works, but it isn't interactive.
Another thing is that they keep removing features. I feel like I'm going nuts, but menu items just quietly disappear, all over the place.
It's Twitter-clones, realizing they can never be a daily driver.
Chat / Community / Group take over = happening.
Slowly but surely 🐢 .
Yeah. The two most viable Nostr models are apps that let you interact online and offline with your various communities (Chachi, PurpleKonnektiv, Flotilla, GitRepublic, etc.) or apps that are specifically-tailored to appeal to one particular community, in each cloned instance (Alexandria, where you self-host it under your own domain and use one list of relays and etc.).
what will be cool is that the network will fracture into smaller communities - all the while identity will remain portable with notes remaining immutable and interoperable.