this post was submitted on 14 Jun 2024
6 points (80.0% liked)
Self Hosted - Self-hosting your services.
11116 readers
1 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules
- No harassment
- crossposts from c/Open Source & c/docker & related may be allowed, depending on context
- Video Promoting is allowed if is within the topic.
- No spamming.
- Stay friendly.
- Follow the lemmy.ml instance rules.
- Tag your post. (Read under)
Important
Beginning of January 1st 2024 this rule WILL be enforced. Posts that are not tagged will be warned and if not fixed within 24h then removed!
- Lemmy doesn't have tags yet, so mark it with [Question], [Help], [Project], [Other], [Promoting] or other you may think is appropriate.
Cross-posting
- [email protected] is allowed!
- [email protected] is allowed!
- [email protected] is allowed!
- [email protected] is allowed if topic has to do with selfhosting.
- [email protected] is allowed!
If you see a rule-breaker please DM the mods!
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
thanks for that. its all sage advice.
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:
there are many p2p chat apps out there. i think mine is most similar to: https://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".
Thanks for the support!