On 2025/03/17 20:37, Christoph Liebender wrote: > Am 17.03.25 um 19:08 schrieb Stuart Henderson: > > On 2025/03/17 18:43, Christoph Liebender wrote: > > > Am 04.03.25 um 17:12 schrieb Christoph Liebender: > > > > Am 03.03.25 um 10:50 schrieb Stuart Henderson: > > > > > On 2025/03/01 19:47, Christoph Liebender wrote: > > > > > > Comments, ok? > > > > > > > > > > the readme should follow the template used in other ports, see > > > > > /usr/ports/infrastructure/templates > > > > > > > > > > I don't have time to look further today > > > > > > > > I've made the readme follow the template. I've also shortened it a bit > > > > for it to be more concise. It is attached. > > > > > > I added myself in the MAINTAINER tag as per suggestion in the net/wstunnel > > > update to 10.1.10 . Attached as tarball. > > > > I took a look at the readme but it doesn't really have enough > > information to get it working by itself. Then I looked through the > > readme via https://github.com/mollyim/mollysocket and it's not very > > well structured, has a lot of references to irrelevant Linux-only > > things, and is lacking information too - it talks about "the Android > > app" but doesn't say where to get it and my searches in play store > > just return irrelevant things. A simple step by step would be quite > > helpful. > > Well, what kind of person should the README be written for? Someone who has > never heard about Molly and just stumbled accross mollysocket in the ports > tree?
That sounds about right to me. At least enough for people to 1) figure out whether it's useful for them, and 2) get an idea of what, other than mollysocket, they need to use in order to run it. This shouldn't need to be (and is better if it isn't) in huge detail but upstream's install docs are all systemd/docker and don't explain this very well either so I think in this case the readme will need to take up the slack. > I'd say the motivation is like this: established Molly users learn > about the possibility of ditching Google notifications, are interested in > implementing that with their server / VPS box, and discover the OpenBSD > port. Then, the README supplies OpenBSD specific info for setup. The headline text in the port description is "MollySocket allows getting Signal notifications via UnifiedPush" so I'd say it needs to cater for someone who knows about Signal and not Molly, and probably only a partial understanding of UnifiedPush. > Sure, in the end you'd need some kind of relayd/nginx reverse proxy setup in > front of mollysocket that terminates TLS, but isn't that out of scope? > Especially because there is the possibility to run mollysocket in airgapped > mode, without any reverse-proxy in front. I don't think including full details of the reverse-proxy setup are required here, and I certainly wouldn't want full blown "this is how you install $proxy, this is how you get an x509 cert, etc etc", though a quick config snippet as an example certainly wouldn't hurt. > Adding a link to Molly in the README, sure, that can be done. For your > reference, Molly is not available on the Playstore nor F-Droid, you need to > resort to one of their distribution channels: > https://molly.im/get.html > > What is the scope on READMEs? Or: where does it say what the scope is? Varies depending on the quality of upstream docs (here, they're more focussed on what it does/how it works rather than what the user needs to do), how complex the software is (several other pieces of software needed; for some there's only one choice so it's easy, for others the user has to choose), and how much of a special case it is to run on OpenBSD (not particularly). If I got it right, users will need: - molly.im on android (sideloaded or 3rd party app store) - some unifiedpush client on android (sideloaded or 3rd party app store) - some notification server, either self-hosted or 3rd party - mollysocket, on openbsd box/etc - reverse proxy / tls wrapper, or follow upstream's 'airgapped' docs then, they need to know if their push server supports a VAPID key (whatever that is) and generate if necessary, authorize it to the push server somehow, work out what to put in allowed_endpoints for their choice of push server, does that sound about right? There are a few things that you've figured out over time in order to run this - a good readme will impart that information to the prospective user without too many diversions.
