My step-up from Pi was to ebay HP 800 G1 minis then G2’s. They are really well made, there’s full repair manuals available, and they are just a pleasure to swap bits in and out. I’ve heard good things about, and expect similar build quality from the 1 liter Lenovos.
I agree that RAM is a likely constraint rather than processor for self-hosting workloads. Particularly in my case as I’m on Proxmox and run all my docker containers in separate LXCs. I run 32GB in the G2’s which was a straightforward upgrade (they take laptop like memory). One some of them I’ve upgraded the SSDs, or if not, I’ve added M.2 NVME drives (that the G2’s have a slot for).
I like getting Bee-link boxes - they can be upgraded to 64gb RAM, have plenty of CPU, and can have two drives. I run Proxmox on them and make VMs that then run my services in docker.
There’s been a lot of talk about N100s as well. I haven’t looked into them much, but I assume they should be similar. Looks like their max memory is 16gb. I’d stick with Bee-link.
its been compared to simplex before im sure there are some similarities. its important to note that i want to make the app more accessible to users by providing it as a webapp. this allows for things like easier network inspection.
it isnt defined well enough to be documented. it is using a combination of the details found in the following links. the project in general, is lacking documentation because it is low prio for me.
I’d suggest writing at least some level of documentation for the protocol. I’d assume a lot of the more security-minded folks – who your app seems to be targeting – won’t be too enthusiastic about using a chat service that promises security but doesn’t tell you how it plans on achieving it.
your caution is well placed. this app is not ready to replace any existing app or service. it is only provided for demo and testing.
the feedback ive recieved from security professionals is that the project is too complicated to review without a budget (which is understandable). so i think updating the docs is something i will do when i have the protocol and algorithm better defined. (note: i am already planning on breaking changes, but havent found the time to do them.)
But yeah, after glancing through the links you provided, I’d agree that you’ll definitely need to pay someone for an audit / review, there are so many pitfalls and gotchas when it comes to encryption alone, and depending on the guarantees you want to be able to make you’ll find even more pitfalls and gotchas – especially if you want to make even relatively light guarantees about anonymity. The classic problem is that even with encrypted payloads the metadata / protocol itself leaks information, which might or might not be a problem depending on what your guarantees are.
yeah. i find its difficult to gain traction from security professionals on this project as an individual. because from the onset it is pointed out that im not a cybersecurity professional (which is true).
when looking a security guidelines from things like OWASP i already notice that there are things like having every PR reviewed and other hoops i have to jump through to make the app secure as defined in those guidelines. i also notice there arent any guidelines for p2p apps and if i proceed with my own interpretation, it would undemine the guide. here is a question on reddit on the matter: reddit.com/…/security_guidelines_for_p2p_apps/
I have a background in distributed systems and some background in security (I’m by no means a cryptography expert but I do know more about the subject than average developers), and I’d say that at this stage you shouldn’t worry too much about meeting all parts of some guideline or another; they’re often geared more towards bigger teams and slightly more established projects. What I think could benefit you would be first of all to have a clear idea of what exactly you want to accomplish (from a security standpoint, not necessarily so much from a functionality standpoint) if you don’t already have have one, ie. what sort of guarantees do you want to be able to make. Doesn’t have to even be a public document at first, just some notes and sketches for yourself. Then you’d want to find other projects with similar guarantees and aims and see how they did things, find research papers on the subjects and so on. Security guidelines can be useful, but generally it’s more useful to understand why something is in a guideline in the first place. For a project such as yourst I would personally really emphasize design documents and research over code at an early stage, because you need to have a clear goal in mind before you start cranking out code which might turn out to be worthless (at least to some degree) after you run into problems with your approach. Not saying that the documentation has to be public, just that you / the team know exactly what the goal is.
“Encrypted P2P chat” can mean vastly different kinds of projects, with very different aims. For example, do you want perfect forward secrecy? If so, you’d want to find out the challenges associated with it, especially in relation to interactivity since you’re building a P2P architecture, etc. etc. Same with anonymity / user “traceability” like I mentioned earlier; you need to have a clear picture of what kinds of guarantees do you want the users to have to be even able to say what kinds of best practices you’d have to follow.
Sorry, that turned into a bit of a ramble and might be completely obvious to you already, since I have no idea about your background and the level of research you’ve already done.
im happy to proceed in the public with the apps development. i am generally going for a release-often approach with the code and id like to make decisions public early. as a regular js developer, from a security standpoint id like to aim for as secure as possible.
guarantees?.. not sure what this would look like when presenting this publicly. my app is a webapp and the key pillars for its security seem to be:
that the browser cryptography functions are not compromised.
that the peer/device/os is not compromised
there are many p2p chat apps out there. i think mine is most similar to: chitchatter.im … but i think its important to note, as a sideproject, i am also trying to be creative with what is possible with browser technology to set it apart from what else is out there. to create something bare-bones would not be attractive to users. one of the first things i did on the project is the security implementation and then built the other details on top.
id like to make it clear that the app is using webrtc which requires IP addresses to be exchanged which could result in IP address being exposed when using the public peerjs-server (hosting your own is an option). this app is explicitly NOT for anonymous communication. it explicitly shares IP addresses and data sent/recieved from peers cannot be moderated. the app is using cryptographically random ID’s for profiles to make sure they are unguessable. you should not post your connection data public. it would undermine its unguessable-ness. this is why i have wording throughout my docs to say you should only connect to peers you trust.
there is also the elephant in the room… the stability of my code. id like to confirm at this early stage, it is not only unstable, but there will be breaking changes. i think its important i mention these details to help users manage expectations of the app. the security implication is that the app is not secure because of this alone.
as for the project vision of how and what it does, i have generally expressed it in my reddit, but i find that the vision is not so clear to grasp, its mainly that all the parts will fit together. that is hard for me to explain and harder for anyone to understand without it working how i envision. its hard to explain: “decentralised p2p chat app on a blockchain with shared AR and filesystem on the browser”. from a security standpoint, as secure as possible with javascript.
With “guarantees” I meant things like whether you want to have perfect forward secrecy, or whether you want to provide some degree of deniability, and so on, not so much what kinds of guarantees you’re relying on although they’re definitely also good to keep in mind.
“As secure as possible” is a very all-encompassing goal which doesn’t really say much – what I was trying to get at with my point about the guarantees you want to make is that you’ll want to have a clear idea of what you actually mean with “as secure as possible” so you’ll know what sort of eg. architectural decisions to make before you do a lot of work and paint yourself into a corner.
It’s a very ambitious project, but I can guarantee it’ll probably be very interesting to work on and you’ll learn a lot regardless of the outcome, and I’m definitely rooting for you.
Still not sure what “guarantees” should look like. As a webapp there are some hard limitations on what a website can do on a browser. I guess that needs to be encoded.
I’d like to have all the buzzwords like forward secrecy and post-quantum proof. I don’t know enough to list them all, but keen to see what else I can accommodate. When I say “as secure as possible”, it might be better to interpret that as “aiming for the stars to land on the moon”.
Not sure what it means to “provide some degree of deniability”.
Ha, we’ve been doing the same thing for the past few months! I just made a generic Immich account that we all log into and upload to that. I auto backup the library to other places as we go, just in case. Once we’re done, we’ll all get copies of the directory to do with as we please.
I have Immich set up to keep the name of the files instead of giving them a random name. As we scan we name the files with the peoples names and generic tags like Tom.Mary.Birthday.1992 and putting Mary before birthday indicates that it was Mary’s birthday. So that if I decide to try and add meta data to the files it will be easier.
I haven’t figured out a plan for adding meta info to the files so they at least have the year/month they were taken and I don’t know if I even want to since we’re 1000’s of photos in now
Ok, I like this idea. Handn’t thought of doing a single library we all log into. That certainly could make things easier since I already have the server up and running.
80 and 443 are the standard ports for webpages (http and https respectively). Lot of selfhosted software with web-based frontends will therefore try to use them.
You can change the ports for the bitwarden container to whatever you like, but the “proper” way to set up multiple services with web-based interfaces like this, is to use a reverse proxy to make them all accessible via these two standard ports. (Caddy is popular for this)
You can then access them using their respective subdomains or subpaths.
With vaultwarden it’s very easy, just change the port map in the docker compose file on the host side. No idea how to do it with the official server stack.
@GregorTacTac If you use containers you can map something like 8080 on the host to 80 in the container. Generally it's recommended to have a reverse proxy listening on 80 and 443 with all your individual applications on localhost only high ports.
Bitwarden has its own script to manage the containers. It’s not your typical self hosted app docker installation. What OP is looking for is easily accessible in their FAQ section of the documentation.
Q: How do I use custom server ports?
A: To use custom ports, instead of 80 and 443, edit the http_port= and https_port= values in ./bwdata/config.yml and run ./bitwarden.sh rebuild to rebuild your server assets.
Check that the custom port values have been proliferated to ./bwdata/env/global.override.env.
A: To use custom ports, instead of 80 and 443, edit the http_port= and https_port= values in ./bwdata/config.yml and run ./bitwarden.sh rebuild to rebuild your server assets.
Check that the custom port values have been proliferated to ./bwdata/env/global.override.env.
Unfortunately, I’m not familiar with installing Bitwarden so I can only offer general advice.
Port conflicts happen at runtime, not when software is installed. In general, you should be able to install as much software as you’d like that all relies on port 443 but only run one at a time.
If you’re seeing port conflicts when installing Bitwarden, then I suspect that something is starting the app after the install is done. If this is right, then maybe you can disable the automatic start. Or maybe you can ignore the error at install time, then configure the app, then start it.
I think that CPU only supports up to 8GB RAM. Also the m2 is only for Wifi cards I think.
I have a somewhat similar ASUS board and it is quite ok otherwise, but don’t expect wonders from that CPU.
A bit annoying will be that you need to either use one of the four SATA ports for the system drive, or find some way to boot from the PCIe 1x port. The similar ASUS board that I have does not support booting from NVMe drives though, so even if you added an adapter for this it probably wouldn’t work (maybe if there is an BIOS update for it).
You could boot from a USB3 drive… not ideal but workable. Or add more SATA ports via an PCIe 1x extension card… but those might be hard to find, usually they require a longer (4x?) PCIe port.
P.S.: if you end up buying that board I can sell you 2x 4GB DDR3 SODIMMs that I have currently no use for :p
Hard to argue with Intel, but I run one of the asrock j3455 boards (with a full PCIe slot and 2 SATA ports) and powershell is reporting OSTotalVisibleMemorySize of 12228504.
selfhost
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.