It's been so weird working on nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz  because we're now 10 people and it took forever to collect the group and get the infrastructure setup and write the scripts and figure out where to put the docs, and figure out naming schemes, and decide which products to build, and draw icons, and rent relays, and learn how to make repo events, and select frameworks and tools, decide on languages and network with people making similar products, and and...

But, now that's all there and we can just... work.
It's getting interesting.

Feels like we've hiked to the top of some sort of mountain and we can just glide down from here.


Feels like maybe, but i suspect there is more to come. But according to what you say, the most difficult part is over. Also you have to avoid the "curve". It is a usual situation when team projects reach a peak and then relax and the project collapses.


Sound like an ad for the Hill Charts.

https://image.nostr.build/8dd303d520f6c1df0d4da601d8dbfad887cb7421a1a96d309f8482b2618588bf.jpg

IMO, the most effective to quickly communicate where you stand with the project.


I'd be more worried about corrupt donors trying to capture the project, bringing their own devs, astroturfers, etc. and pushing "feature creep" as hard as they can in ways designed to interfere with the original underlying functionality

Also heads up for the whole new nostr protocol v2 that will be built by me or someone like me, that might be a difficult adjustment


See also: Linux / GNU / Ubuntu / Canonical


Linus Torvalds may never relax


Ah well said 👍


I never relax. 😅


We have a very stable PO. Not worried.


10 people?!?! wow, that is very likely the largest single-team working on nostr


who are the 10 people btw?


Git oriented people on Nostr!!!! We need to talk!! I did a thing: https://github.com/gugabfigueiredo/git-remote-nostr


Yes, I think so. And we have all project roles covered and full infrastructure.


Excited to see what you all come up with. I wrote this a while back sort of as a thought experiment. Didn’t have the dev skills to try to actually build something like this. note19a92009jxr0jk36pxqtg8z85keku945a6pjq58maqhgj7vmsyx7sqrrnu6


This is awesome.  I was just talking about this with the other nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz folks yesterday.  Nostr-native identifiers for Git repos is the next big step in powering up the Nostr Git ecosystem.


Wut?!? 😮
https://m.primal.net/JCOj.jpg


We would actually want to clone from a repo event, I think, using naddr.


Cool! Glad to contribute! Any feedback is appreciated


I starred the repo so I can find it later!  We're planning to do some work with Nostr repo identifiers, so I'll either use the package directly, or reference it as an example implementation (and credit you for it) when we get to that point in our project.


Many thanks! Much appreciated! You made a dev happy today. My first zap for the effort!!


Interesting project!
Can git run over http? Please have a look at the NIP that I’m working to implement:

https://vimeo.com/950881613

https://github.com/nostr-protocol/nips/issues/1276


Yeah, crazy timing. 😂 Great minds think alike!


If were the largest organized group, we still have a large mountain to climb. Good thing I've been getting in shape


Onward 🫡

Onward 🫡


I have no knowledge at all, I don't even know I'm typing this reply. I'm just hitting touch screen buttons randomly because I like the colors they make and if it's forming words or sentences, that's pure coincidence.

On this basis I ask, what it do?


You can find someone's code repository, in order to clone it, by using a Nostr address instead of GitHub or whatever.

We have a use case for this with Ngit.
 #[4]


Wow. I’m impressed. A vision AND a blueprint AND a team to build it all. Downhill never looked so fun.


We've been doing this sort of thing for other people. This time, we work for ourselves.


Can I DM you?


is that a technical question xD


How flexible are you on the golang thing, Mleku? We're very C-heavy.


Like, do you think computer languages can coexist, or are you a virulent golang maximalist?


Asking for a friend.


I can't tell if you're offline or if you're staring in horror at my question.


i can live with C but i am not familiar enough with stdio.h to actually do anything useful

but maybe after a few weeks i'd be able to iterate arrays and suchlike

i remember how to do pointer arithmetic and all that, the logic control is very simple and inflexible

i hate the build system though, never did actually grasp how it works, or why i have to repeat my function signature lines in a second.h file, something to do with each C file being an independent binary object so you need to tell the importing code the way to construct valid parameters

let's just say, it's hella primitive and i can do a billion times more with Go, with far less chance of a nasty stack busting bug


i guess that's a "no i'm useless to you if you need me to write memory handling" i have a vague concept of how to do it, and i can probably write it really well but it will take me at least 10x longer to do anything, and 100x longer to actually debug it

seriously, i'll just say no, i can build components especially microservice type things and servers in general, code generators, such like tooling, i can invent APIs and codecs, but memory management at that level of irritating detail is just inhuman


Okay, fair answer. 🫂


After experimenting with C++, I rejected it as combersome, slow to compile, and few benefits (such as golang and rust provide).  Rust is even slower to compile.

I stole some C++ concepts for C, using a nexted exception analog with try/catch macros and also swiped obstack from gnu compiler.  Thus most memory management is automatic with obstack freeing objects from more deeply nested levels.  Objects point to a class structure with function pointers for virtual methods.  Virtual method calls use do macros.  As in x = do(obj,parm1) or do2(obj,p1,p2).

Archive of sql implementation using that C style: https://github.com/sdgathman/btas/tree/master/sql

In contrast to nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ahx7um5wgh8w6twv5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshszythwden5te0dehhxarj9ekxzmny9uq3wamnwvaz7tmdd3jkkafwdehhxarjxyhxxmmd9uqsuamnwvaz7tmwdaejumr0dshsqgzvsqp90fvg4q5yn5zfs97zhk4dnp9jtfz6m8md44nwglfmgl3m9ucrxauz  , I consider the golang/npm/rust library repos dangerously fine grained.  Instead of a few dependencies with trusted maintainers, a golang project e.g. has hundreds of dependencies by little known individuals - any one of which could have (and has had) trojans built in.  And these contributors can artificially boost their reputation by e.g. [reputation farming](https://seclists.org/oss-sec/2024/q2/304).

Large topical libraries like glibc or libsodium are much more manageable.  Golang projects are extremely cumbersome to build for projects like Fedora with reproducible builds.  To me, it is insane that people type 'go build' and get the latest code from random strangers on the internet integrated with their binary.  Now download all 200 dependencies, at least eyeball the code for all 200, try to check the reputation of a random sample of the 200 contributors, check the LICENSE of each dependency and compatibility with your license (and Fedora policy) - and THEN tell me how "easy" golang is.


I have lots of languages coexisting from EDL to Java to C++ to C to Python.  I integrate with message passing / RPC, so there is no issue with binary compatibility.  Struct/copycd/class versions of data layout are easily translated automatically.  My brother uses JSON source for data definitions, and translates that to headers/copycd/etc for various languages.

A lot of people use JSON for messages.  I respect that and have no problem interacting with that, but it is slower.


brk(), sbrk() lmfao


Actually fun part. My noscrypt makes no calls to allocate heap memory. So much C work can be done on the stack or in the data segment.

I do maintain forks of mimalloc and rpmalloc for my C# framework  which is fun.

Take a look into the Cosmopolitan libc and APE loaders which is a pretty awesome project I like to hang out around
https://github.com/jart/cosmopolitan


i am aware of the uses of stacks

i generally try to use stacks and even registers, it's one of the things i loved about the m68k architecture, so many registers you didn't even need a stack to make many calls, a large number of the improvements that have occurred in the Go compiler output have been achieved through more use of registers, they are the fastest memory in a computer and it's insane how a register-poor architecture like intel has come to dominate, just a reflection of how much abstraction and the bloat it causes is the norm


it is obvious that you haven't worked with go for a long time because for some years now go.mod files show you literally every import, both the ones named in your sources in the repo, plus all the ones that are named in the ones you imported (go mod tool puts `// indirect` after them)

and i concur with your opinion about the thoughtless use of packages without considering this, i'm obsessive about how long the list of imports in my go.mod gets, and when i see repeating ones i get stressed

this is why i put my "nostrbench" package in a completely separate repo from my code because i don't want it polluted with fiatjaf's infinity imports, and all the crazy versions

this is also why i have reworked the entire btcec library to eliminate, for one thing, the decred dependency, and i've mostly also removed its dependency on blake hash library except for a few tests that i have to regenerate vectors for

the go standard library itself has a lot of things but some things are glaringly missing, and especially when it comes to go's crazy immutable strings, the amount of memory garbage these throw off is mindboggling - the more complex your application, and the longer it runs for, the more likely you are to run into GC hell with high CPU usage and reduced latency after a certain amount of time, and even worse if you are spawning coroutines for each network connection and those damn connections never drop (this is a problem with the design of nostr websocket subscriptions, and there is no specification about what constitutes an expected time to drop a subscription beyond exceeding the configured limit field in filters)

i am not overtly conscious of the fact that huge long go.mod files could be a security problem but now you point it out, yes, this is another reason, but my primary reason to not want that is to not fill my disk with useless, often unnecessarily redundant crap, it clogs the disk, for a start, and then in the actual binary, it means several pieces of code do the same thing in different parts, this annoys the piss out of me also, and it's more memory that is going to waste, and then on top, very often the entire architecture of the different components is not in line with my architecture and all my efforts to maintain sane memory usage are defeated by some stupid import of an import of an import


also, again, it's obviously been a while since you used Go because building a Go app anywhere has been the same since around 2018, it's more reliable and fast for building packages on any system than any other language i know of, literally you can just

go install url.of.repo/path/to@latest

and if you configured your path correctly to point where GOBIN has been added, it's instantly available


Yes, I am perfectly aware that "works".  You missed the point that that does NOT meet the standard of packaging I insist on, and that distros like Fedora insist on.


yeah, and as such have a very difficult time changing the repository or eliminating dependencies

thus we have perl, python, gcc, clang, and a whole bunch of other things in there because the tree of dependencies is more complex than a 1000 year old ficus' root system

this is also why Go itself pioneers the concept of multi-binaries, an idea which started with busybox

every architectural and engineering decision has consequences and you should not ignore the outliers that your chosen one gives you

and it's a hard problem to fix because of the highly decentralised open source development ecosystem, that's why we still have perl even though you can do all that stuff with C or python


CISC generally does not benefit on a larger register file due to deep pipelines and hyper-threading. Stuff needs to get in and out of registers fast, it also helps with context switching and branch prediction. Again for deep pipeline times L1 is only a few cycles if that.


also, it's a bit of a foggy domain this issue lives in... normal packages don't alter the rc files of shells, there is one main one in /etc and when you install Go it doesn't add to that

in fact, it should be obvious that the shell configurations should actually have a `shell.d` directory which would facilitate that being non-destructive or racy

i like how modules freeze versions of imports and ensure they are valid via git hashes but it was one of the neat things about GOPATH - like the old days of BSD with the /src directory

now, that is something i would like to see come back... pure source OS, so you literally on install drop the source of everything core, bootstrap the compiler and then build everything, using a Go style caching/modula style build cache, and that would also make it a bit easier to introduce dynamic linking if there was a 1:1 between source and binary

probably something that will eventually come in the future... there is already efforts in this direction, and some notable historical attempts towards this kind of goal such as Oberon and Oberon2, actually, one of the earliest, and probably closest to what we see now with the javascript/browser platform was the original Smalltalk, and notably one of Go's founders, Rob Pike, at one time attempted to make a GUI oriented, CSP concurrency language for programming UIs that looks remarkably similar to Go in many respects, the basis of much of the concurrency for sure, and some of the dynamic array stuff

anyhow, it just seems logical to me, if you can have a non-rivalrous namespace to pin every piece of software into, and you have a versioning system that lets you build off a specific version, the really hard problem at this point is still the namespace, and i personally feel that Git overcomplicates the versioning history a little


yeah, that's further parts of the reason why i prefer the AMD Zen architecture, because they have simplified the units so much they are literally little sub-dies across the chip instead of a complex whole design as is the norm with intel's engineering

the trend is towards more parallelisation, this helps with latency as well (lower distances of travel) and simplifies manufacturing (less risk of errors in the design due to a simpler design)

as we have seen also, where for a long time intel, notably with the Atom, was getting a better watt/compute ratio 10 years ago, this is now moving in favor of the simplified, parallel architecture of the Zen chips, and i expect the same trend is happening with ARM and MIPS processors as well, with their lower overall engineering budgets versus intel

the difference between SIMD performance on wide bit sizes is phenomenal, i am hoping that some day soon someone makes an secp256k1 signature function in AVX


I am not talking about runtime dependencies, which multi-binaries and busybox address.  I am talking about the source code dependencies.   When you have 100 times the number of entities (persons/projects) providing the source code golang pulls in for the easy-peasy build, vetting is 100 times more work.

I really admire the lightning fast compiles of golang and the language features - but the security nightmare of their standard repo is something that younger programmers don't seem to understand, and is shared by other new languages.


indeed, along with numerous other features i'd razor out the stdlib (strings is another feature i'd remove)

i'm a rabid golang maxi... less features, more security, more speed


for sure the stdlib is the biggest anchor dragging Go down


aside from strings


yes! also, i want to rewrite the damn golang stdlib, after i rip out the damn string type

also need to change how it treats methods of reference types (slices, maps) so they behave the same way as pointers

these are the two biggest gripes i have with Go

and don't get me started on the math/big library, what a shitshow


Good chance I will soon :). Likely some ASM because supporting the cross-arch SIMD instructions is a pain in itself. AVX is pretty old now


i'm sure i could do it given a month time window, i have reasonable familiarity with assembler syntax in general, and have done a lot of work with iterative operations

just haven't had the time to actually sit down and do it, if you get going on it, i'm keen to follow and if i can, help out

i'm already ridiculously curious about what AVX assembler ops look like


Sounds good I'll count you in!


gotta follow ya then lol