Giving up on #strfry. Copying binaries didn’t work, some lib file missing or something. #Haven looked interesting, but it’s a personal relay and I’m trying to set up a special purpose public relay. Switching to #nostream aka #nostr-ts-relay. I had hoped to avoid the whole need for a Docker containerized setup, but here we are. Nice thing about the latter is that it’s in TypeScript, so there’s a chance I could contribute features if I need to.
what do you want to do exactly?
I’m using Nostr as the communication mechanism for a special purpose site. Nostr is not the focus, just the user-generated-message sharing provider. My app sends custom events (unclaimed kind number) with empty content. Tags contain all the relevant info. Users’ nsecs are randomly generated. I may later allow profile features, but for now it’s irrelevant. So I need a relay with the following features: 0. (Required) Installable on my lowish -powered Ubuntu VPS. 1. (Required) Allow public access over SSL. 2. (Required) Persist events. 3. (Nice to have) Basic throttling. E.g. limit to 1 published event per second per IP address. 4. (Nice to have) Event kind allow-list. Disallow events of all kinds other than a specific short list of kind numbers. 5. (Nice to have) NIP-13 Proof-of-Work enforcement. Alternative to basic throttling.
docker pull scsibug/nostr-rs-relay docker run -p 4445:8080 scsibug/nostr-rs-relay
yeah this is the rust relay
I think it is still the best, because it is simple. Everything else is exploding in complexity.
Looks like this is going to have to be my next attempt. nostream’s dependency on Postgres failed to start.
Nostream is barely maintained. I dont like postgres too much, but will use it when I have to.
OK, I am now running the podman command from the nostr-rs-relay README. Let’s see if my VPS can handle it. Compiling… https://image.nostr.build/de731a1305e90e1e44133daf297c1745ceed7ddb1c45641620ebef1725d270e2.jpg
interesting, and you've tried strfry and failed? There was a rust relay that I saw a while back that seemed customizable, can't find it though. Not really sure what's entailed in building your own relay from scratch, but that might be a good place to start for custom use case? If the requirements are the same across relay functionality, then maybe you can build the foundation and then your "nice to haves" on to of that? Or maybe you've tried this already? strfry was easy to use and install, but I never really tinkered with it more than was required. That rust one also looked good, but i don't know rust so I left it out. The other relays were like personal relays and stuff. Someone who would know would be @verita84 but I think he's moved away from nostr to something else.
Sounds like he needs strfry or ditto.pub
Yeah, strfry was too beefy to compile on my VPS. Copying the laptop-compiled binaries failed (something about a missing lib*.so file). Tried nostream, but its dependency on Postgres wouldn’t start. Probably to little memory in both cases. I have gotten nostr-re-relay to work, so I’m going with that for now.
i'm not sure if you are even reading my notes but i literally just built and am running my realy relay on wss://nostr.realy.lol this evening and you already have access to read and write to it if your client auths to confirm you are one of my follows it took a bit over a minute including download time to build it on a 1gb memory VPS you should be able to get any Go based relay to build from source in even as small as 512Mb of memory
I am reading your notes, but they don’t apply to my use case I don’t think. My users have randomly generated nsec that they don’t even see. No profile info. No standard event kinds (no 0, 1, 2, 7, etc., just custom events) So there can be no “follows” or web of trust etc. For my use-case Nostr is just the messaging protocol between anonymous contributors who don’t interact directly and have no in-app means of doing so.
well, i'll leave off on commenting because i think you are doing something that will prove to be a waste of time
No problem, it might be! Here’s a brief description of what my site is about: nostr:note1wntnh2napy79s4yj7dc4uxh4hqxrzc0297yqcnqtnq3ry0rjjkpqn0ams3
I forgot my password
ditto uses your nsec
No I mean on pleroa
will dm you password reset link
thanks bro
they link may not work, if so, I will manually set a password
Docker is your friend
It’s a complicated burden
Simplifies distribution and orchestration. Definitely not a good fit for all use cases, but on a server it'll generally make your life easier
After a fashion, probably. But to use Docker at all you have to first install it, which you can’t do from the package maintainer. So you’re either out in apt sources config land, or installing deb packages by hand. And then you have to configure your user to be a member of the docker group. And then you can start using docker, which may include configuring your virtual network, and port forwarding from the system proper. And setting up persistent volumes. Compare that to “sudo apt install <whatever> “.
what's wrong with podman? should be in your distro
I have never heard of that before today. Saw it mentioned somewhere in some document. What is it?
think of it as drop-in replacement of docker in that case (there's a rabbit hole involved).
https://media1.tenor.com/m/wPUbkhwfiuEAAAAd/curiosity-curious.gif
nspawn is more lightweight than docker, no layered filesystem... but you have to bring more batteries to it... i never even heard of it until a year ago, it's a great way to put services in containers https://github.com/relaytools/relay-tools-images i helped build this
Reminds me of OSv unikernels. Still think it's the way to go. you can use this for go apps. have a look!
yeah, it had go in it because cloudfodder was building strfry sprockets in Go and it was simplest to just write a script to install go and git and pull the stuff go and git have got to be the smallest footprint dev toolchain there is, anyone that doesn't get how powerful that is is just not thinking
oot. just generally, do you like the unikernel idea?
i was very interested in "NoKernel" even more, and have even thought of an idea of having a kernel running on each core of a CPU with a message passing interface plan9 also goes towards this direction as well, by creating a uniform socket interface for everything, the next logical step from the unix "everything is a file" but android also with LXC namespace isolation goes a long way towards this also and i get it that this is what UFS and ZFS are trying to do to filesystems but really LVM2 does it better overall, you can conceive of a single service that just manages this, and another service that manages permission, like a local version of ETCD i think it's gonna be a long time yet before we see the end of monolithic kernels though... apple runs on a bsd microkernel and everyone else is running monolithics i think really it's just about the API differences, it's hard to make a mapping between standard system APIs and the distinctly different way you run things with a no-kernel everything-is-a-service style of architecture... the slowest moving parts of software development are languages and kernels it's a subject dear to my heart though... kernels and compilers, my two favourite things
i'd like to see something like qubeos but instead of fat vms it would spawn unikernel adhoc vms with apps. those two models merged would really be awesome. much more efficient then flatpak or snap.
This is a good point, I should have said "containers are your friend". Any OCI compliant runtime simplifies server administration
OCI?
It's a container format and runtime standard. see, a rabbit hole 😂
Part of what I dislike about Docker is the “you have to understand everything to do anything” nature of it. 😅
As an admin you (almost (until you figure out how things don't respect the specs) never) have to. alias docker=podman
*don't have to
The fact that you’re making your point with nested parentheticals and footnotes does not fill me with great confidence 😂
Hey, I'm trying hard to be funny 😂