Oddbean new post about login | logout this is just an observation. when i see a project go silent on the public repos, and then cut a major release from a closed repo. i start to consider their code as open in name only, or vaporsource. it is a code/release pathway that only becomes harder to work with over time as the mainline diverges so much from the sprinkling of source that we get to see. nostr:nevent1qqsdcw5az06zg49rx5qktl78dwlnm8ykawphl0n0yzzmlnwefqehxxqpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crsrqsqqqqqpaw7g2f
All of our code is released on public repos. Please provide examples of where our code is not visible and we will fix this issue immediately. We believe in remaining open sourced.
https://github.com/PrimalHQ/primal-server and https://github.com/PrimalHQ/primal-caching-service is main branch what you run in production? having a main branch and tags for all repos is what i'd like to see
not that primal will see this .. but maybe. just maybe, if i boostquote it.. they seem interested in how to push their code 🤔 or simply confused that anyone looked. nostr:nevent1qqs290j84axd32qqwjv3ycyr8cn9rpeqs8dv49fuwy4k0d9rp9crk2gpzdmhxue69uhhwmm59e6hg7r09ehkuef0qgs8eseg5zxak2hal8umuaa7laxgxjyll9uhyxp86c522shn9gj8crsrqsqqqqqpzv5ldx
its all open, the development is just happened in the dev branch (accessible from anyone on guthub)
I was wondering where this came from. Nothing since Aug 29 and then a gazillion commits from 1 hour ago.
guys, are you understand the concept of branches? It has been all public in dev branches, I lurked commits real time during last months
https://github.com/PrimalHQ/primal-caching-service/tree/dev this dev branch is 100+ commits behind main
ponymontana literally posted just a few days back about how he'd been spying out some big movements on some repo, i guess maybe it was primal?
yes, at least android was all open in dev branch, every commit has popped in real time in the past months
caching service is not supposed to be delivered as binary and its possible it has not been uptated at all. The source for all platforms where they release binaries have been updated real time. I'm at least 100% sure of android as I followed development directly for last months
guys, are you understand that you shouldn't be working on a branch for months without committing to master? 490 commits without a merge to master. 🥴 The 90s called and they want their waterfall model back.
yeah, partially agree..
you can waterfall all you want, major releases need tags or it didnt happen 🌊🌊🌊
love the waterfall ref tho for real haha 😂 brings back some memories 🌊 of the pre-git era
I'm from that era. 😂 I was hoping it is now very dead. Yo, continuous delivery is what I'm used to now. Even waiting a couple of weeks for bug-fixes is nerve-wracking, but they've left me hanging for 3 months. And we fork from master, not from all branches.
I'm still hanging, by the way. 😏 I'm apparently supposed to search through this alphabet soup, to keep up with development, even though they haven't even responded to the issues I've submitted. 7 months diff between dev and main. Okay. Whatever. https://image.nostr.build/eafebaedff921f54847febd4b36b15613fa8283a1557d1c645bc2245100f171d.jpg
I don't like a master that isn't completely stable though. Lots of big projects without a stable master. For me, master always builds and produces a ci/dev release until tagged. Develop branch is for staging.
If you're a team developing full-time on a project, you should be releasing a stable increment every couple of weeks, at the latest. Gigantic merges are impossible for humans to review, and it means we have to beta test the entire thing, at once. The users just mass-downloaded this, even though it's been off in a dev branch for months and is a major release (even if it's missing some of the changes I expected, like improved login).
I mean, everyone just trusted them and downloaded this monster. The whole point of open-source is that you don't need trust because the development is conducted in a maximally-transparent manner, with frequent releases facing scrutiny by the end users.
sometimes i wake up and decide to run some opensource. i would have run a primal, but i didnt even get to the clone.. because i realized, the code is gone.
agree with you and there is absolutely great value on releasing all backends (and shame for who keep it close). Still the drama about "users trust" is nonsense.
No, it's not. That team has a big trust deficit, with those of us who have been here, for longer, as they keep doing weird stuff. Finding out that they ignored the issues and the PRs for the web-app, for 7 months, while fiddling around on a different branch, while everyone continued to fork from main, is like wut. Dev is 585 commits ahead. The last tag is from Aug 31, 2023. This is just weird behavior, for a Nostr project. They're publishing, technically, but doing it low-key and avoiding the social interaction that is typical of FOSS.
nah, there are different ways to approach foss and different sizes and scopes for project. Primal is evidently a more "company-driven" project, and its okay, it has his role in the space. In the end they implemented nips and tend to be compatible with protocol releasing source code for every binary they ship. Also the product is solid, more than most of the community-driven projects can be, due to more resources invested. I also prefer to use and contribute to more community driven projects, and I think that they tend to respect more users and become better with time, even if initially they tend to be more buggy and unpolished. But every software has his space, and primal team is definitively a good actor, delivering a fully foss client on multiple platform. And no seriuos dev has forked and worked on main branch without realizing that the company was working on other branches, it require just a minimun literacy and competence to figure out.
Okay, thanks for confirming that the Primal devs aren't interested in working with illiterate, incompetent, unserious people like me, so they're just off doing their own corporate thing. I think I've figured that out, now.
come on, stop this drama, its risicolous.
this is false, they are modern and auditable codebases, and the commits well organized and self-explicable. All is open, accessible and understandable for everyone. The point is that they follow a not so common dev practicing that could let new people on codebase a bit disoriented, but it doesnt impact the possibility of read the code and audit it by any means. Every codebase is different as it could fulfill different porpouses, so this drama is totally nonsense.
i am interested in their backend, when i asked, they didnt have an answer. will they only open the client code and keep server private? imquiring minds.. want to know..
frankly dont know about backends codebases. Its super important to open source all and would be great to have responses about that. Still, backend involves trust in who runs it and offer the services, opening the source doesnt make much difference in reducing the trust that users need to put as theres no way to audit the computation happening in the backed.
opening the backend source, means we can keep primal honest by running our own.. if we cant, thats not very nostr like. if clients all use a primal cache cause its so cool and fast and has all these features, but its closed source, then we didnt accomplish the mission to decentralize. maybe the 3 months of no commits just means there arent any new commits because backend is the same as 1.0. i would highly doubt it. which is why i asked.
agree with you
You heard the man. And stop with the Release 0.1.48 bullshit. When 1.0? Y'all won't even give me a 0.2.0, ffs. nostr:nevent1qqsyaujddmjfed5v6fkv89457a6kun8a8r44r4ffxzmt7ynhh78uyxcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygrucv52prwm9t7ln7d7w7l07nyrfz0lj7tjrqnav299gtej5frupcpsgqqqqqqsndsfhx
What's needed for grain 1.0? 🤔
Check your road map.
We need more people who are autistic about versioning. Says me, who is autistic about versioning.
Your autism and my autism are in sync. Autistic synergy. 🤌🏻
IMO, the main/master/dev branch should always be the default one, and fixes and features should be marked by tags, that's how i do it but some think of the master/main as some kind of precious that you only update every few months not putting the main work on the default branch makes a repo look ded, and it's stupid doing that, branches are not where you make releases, you have tags for releases ffs lol
When the dev updates the default branch I expect to be able to pull it and have it build without failing. My staging branches will never be 100% stable for every feature merge. When it's stable and features are merged, then the default branch is updated. Many times a project's features or fixes take a really long time to get tagged, so pulling the latest tag can be months old, while pulling the latest default may have fixes, so it should compile, period.
that's the conflict, between the "main is the release" and "main is the unstable development" because it's the most visible, if you only allow stable releases on it, the activity you see on the main page of the repo is very slow and seems like nothing is happening building in public is a key part of the social engagement of open source development and for that reason, the consensus is moving towards unstable mains, and forget main, call it "dev" or "development" so it's clearly unstable, and mark milestones on tags, which can be combined with "releases" when a minor or major version bump happens, build out binaries or whatever as the case may be, package APKs etc the main branch SHOULD always build though, when i say development i don't mean unstable as in can be not working but unstable as in, may have bugs still until those are fixed and put into a tagged release with a version number for reasons of how the Go toolchain looks for the newest release or newest tag, it's also important for developers with libraries because the tags are easy to remember and you can write them straight into the module file (like a package.lock, but sorta like a package.json but it's neither)... anyway, the same thing can be applied, not so automatically, with other languages, but yeah i agree that it should build on the main branch, i just don't agree that it should necessarily be working, and that this is what tagging is for side branches make sense only with a very large project and teams of more than about 4-5 developers, and the first level of them usually will be platform targets more so than features... again it depends on the size of the team, two guys on a project mostly you can just work on a branch that's your branch and then merge them up to the development branch when they are building and kinda runing, and when the features are stable, you tag a minor version bump, otherwise, tagging patches for potentially unstable changes, so they can be easily referred to
Are you assuming that they needed 400 commits over 3 months, to come to an increment that would build? They could have been pushing to main the whole time, regularly. This was a tactical decision. They know that everyone waits for main, to start reviewing, because we assume things in dev branches are still too much of a construction site, to make it worthwhile to dig through someone else's code base. The increment is also just way. too. big. Ain't nobody got time to read all a that. Straight to blind install.
Not defending primal here. Defending building things in dev, and testing them before committing to master to keep master stable.
but actually the question is, which branch should be the one people see as "default" dev, or master? one looks like slow motion, the other is active, all changes that are working but maybe unstable go there (they compile, ofc) who is more important in open source? the devs who might contribute or audit or test, or the public? the public doesn't matter, they go to the landing page not the repo
Yup, the active one :Check:
I don't know, but I've been trying to review other people's stuff, and submit issues, and it's just too much bother, in this case. Like trying to interact with a brick wall. They just ignore me, every time, and now this. They're looking for adoration, not collaboration, so I'm not the droids they're looking for.
yeah, i had that with LND and BTCD too
https://realy.lol won't be mean to you tho, i promise
help with documentation and document comments and asking pointy questions about "wtf is this shit bro" will definitely most warmly welcomed
🫡
but you see, for "building in public" having the main branch be stable means you barely ever see any activity at the front of the repo page i definitely aver towards the idea of making the main branch called "development" and it will always compile but it may not be stable and may crash at any moment, and near the top of the readme.md you explain that to build release versions go to the tags page, click releases, to find the actual stable versions
if you go do a survey of many active projects on github you will see that some adhere to your idea of repo policy, while others even label their default, main branch as "development" and tag releases and in some cases the tags are associated with a github Release
yup, that's why the scheme i'm describing is becoming the most common standard, it's practical, it makes the activity visible, and the more people adopt it for their projects the less thinking you have to do when you ask "ok, so how do i build this from source" - it should be boilerplate on readme.md's to have basic instructions about tagging and such... i stick with semver so that's another thing also, with semver you pretty much know that vX.X.0 should be stable, eg v1.2.0 should be a stable minor release and v2.0.0 should be a stable major, and anything with numbers after it is either a fix or some/all of a feature added, and if the commit has no tag then you can expect it to break
i think that if you are going to use git then you must know how to check out a tag and yeah, there should be regular tags i think some people find the idea of having hundreds or thousands of tags some how "messy" but it makes development a lot easier and at least Go tooling tries to use tagged versions in imports so this simplifies the process of referring to it also, semver is not single digits, it should be possible to have v1.2.10000
so, you see why that was how primal devs did it it's not just weirdo golang nutters like me, this is becoming a standard procedure in open source development idk where the rest of primal's team is but miljan is croatian, i think, and this kind of aggressive intellectual process and high intelligence seems to be a feature of slav and slav-adjacent programmers we gotta show the world we are doing stuff, but we also need to make sure people know what stuff isn't broken... the model you talk about is the old model and it is more for a closed source shop whose monityors are internal and can see all the stuff and demand reports on a daily or weekly basis
the logic is simple when i am a dev wanting to hax on a project if the default branch is the latest of whatever actually compiles, that's what i want as a dev wanting to hax if i am a lurker wanting to spy on the progress of projects, the default branch is what shows on the plain link to the repo on github or whatever, and the newest stuff can be easily seen there and one click to watch the commit history making the main branch some kind of monument means i have to click twice or more in to get at what i want to see, and that is shitty it also means when i clone it as a dev, i get the latest "release" version and that is also shitty as a dev
the logic is simple when i am a dev wanting to hax on a project if the default branch is the latest of whatever actually compiles, that's what i want as a dev wanting to hax if i am a lurker wanting to spy on the progress of projects, the default branch is what shows on the plain link to the repo on github or whatever, and the newest stuff can be easily seen there and one click to watch the commit history making the main branch some kind of monument means i have to click twice or more in to get at what i want to see, and that is shitty it also means when i clone it as a dev, i get the latest "release" version and that is also shitty as a dev
your project policy is outdated.
i didn't ask you to, you don't work for me whoever is in charge of policy there is wrong, if the project is intended to be open source open source is social, that's a huge key difference to closed source
also, tags are there for some use case... the obvious one is marking releases branches are cumbersome to move around to, and the whole point of them is people are working on something that isn't ready to tag yet i personally tag almost every commit i hate looking at go.mod files with hexadecimal version numbers in the field
also i should mention that technically you can tag any commit, it's not branch related the relationship between commits and branches is they are blockchains (they contain the hash of the previous) tags are simply labels attached to a commit hash
personally i find primal's color scheme jarring and uggly, like, literally they follow the scheme of colour for the game Kingdom for the bad guys (greedies) https://i.nostr.build/kok9ohBGyoeCO53T.png
agree on this, reminds me to instagram palettes and other corporate bullshit
^ I'm building a container wrapper as we speak!
one of the most beautiful things about Go is you can actually not use containers, but ok
It's useful for isolation. I don't need to keep the build tools on the server. My servers a really stripped down (don't even have git installed) I use podman and compose to build and deploy services repeatably.
well, static binaries, no dependency hell, i got into using it because of C++ and python messing up my VPS and home pc systems dozens of times trying to run especially serves remote code execution vulnerabilities are zero unless the server actually has a programming language built into it, the GC zeroes all memory before using it and it's not difficult to maek sure important stuff is zeroed before releasing it, and there is code fences though i haven't looked at them in a while... i will be soon though maybe to keep the relay identity from being accessible to other processes in the execution environment
Also Go makes me ill and I don't want it touching my systems. It might infect me XD
C++ versus Golang! https://media.tenor.com/3N530xN8frsAAAAC/fight-me-will-neff.gif
Dammit, wrong GIF. https://media.tenor.com/K4nmPepz2XgAAAAC/fight-smile.gif
haha you wouldn't want to long for an easy, sleek build system and short compilation times and not needing to use build tools like make or cmake or whatever
one of the most beautiful things about Go is you can actually not use containers, but ok
It's useful for isolation. I don't need to keep the build tools on the server. My servers a really stripped down (don't even have git installed) I use podman and compose to build and deploy services repeatably.
well, static binaries, no dependency hell, i got into using it because of C++ and python messing up my VPS and home pc systems dozens of times trying to run especially serves remote code execution vulnerabilities are zero unless the server actually has a programming language built into it, the GC zeroes all memory before using it and it's not difficult to maek sure important stuff is zeroed before releasing it, and there is code fences though i haven't looked at them in a while... i will be soon though maybe to keep the relay identity from being accessible to other processes in the execution environment
Also Go makes me ill and I don't want it touching my systems. It might infect me XD
C++ versus Golang! https://media.tenor.com/3N530xN8frsAAAAC/fight-me-will-neff.gif
Dammit, wrong GIF. https://media.tenor.com/K4nmPepz2XgAAAAC/fight-smile.gif
haha you wouldn't want to long for an easy, sleek build system and short compilation times and not needing to use build tools like make or cmake or whatever
It's useful for isolation. I don't need to keep the build tools on the server. My servers a really stripped down (don't even have git installed) I use podman and compose to build and deploy services repeatably.
well, static binaries, no dependency hell, i got into using it because of C++ and python messing up my VPS and home pc systems dozens of times trying to run especially serves remote code execution vulnerabilities are zero unless the server actually has a programming language built into it, the GC zeroes all memory before using it and it's not difficult to maek sure important stuff is zeroed before releasing it, and there is code fences though i haven't looked at them in a while... i will be soon though maybe to keep the relay identity from being accessible to other processes in the execution environment
Dammit, wrong GIF. https://media.tenor.com/K4nmPepz2XgAAAAC/fight-smile.gif
