positive_intentions

@positive_intentions@lemmy.ml

This profile is from a federated server and may be incomplete. Browse more on the original instance.

positive_intentions,

Thanks. I’ve come across tox before. It’s a good implementation. The aim of my project is not to compete, but more to demonstrate a different approach to P2P technology.

A key detail in mine is that it’s made to work in a typical web browser. While things like chat functionality can be demonstrated in our app. The app is capable to do things like shared xr spaces and shared filesystems… Unfortunately those features are still in need of refinement before they become appealing to users, but it works for a proof-of-concept.

positive_intentions,

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.

positive_intentions, (edited )

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.)

positive_intentions,

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/

positive_intentions,

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:

  • 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.

positive_intentions,

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.

positive_intentions,

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!

positive_intentions,

if “trust” in the static files from a url is a concern, (which is very reasonable), you can easily host your own instance.

i think it fits squarely as a “P2P app”. over a hotspot, you can practically send messages offline. im not sure what other qualifiers are needed.

i dont think its ready to be compared to other tools yet. but i would be aiming to make it comparable to something like signal… but it’ll take a while to get there.

positive_intentions,

An understandable view. Not sure what you mean by lengthy, but I can confirm my app is not well documented. If the MDN docs count, its a fairly thin wrapper around the functionality provided by the browser of your choice.

github.com/…/Cryptography.tsx

I’m using webpack 5 module federation to import that file at runtime. Perhaps over-engineered, but it’s so I can keep the crypto functionality maintained separately. That repo is in need of more attention for things like unit tests, but the crypto implementation there is pretty basic.

positive_intentions,

I’m using peerjs-server. I’m also investigating other ways to achieve peer discovery which itself could be quite a discussion.

positive_intentions,

It’s similar to matrix in many ways. The key difference is with mine it’s is purely browser based. Unlike traditional solutions like matrix where you have a (self)hosted server, mine does not require things like registration or installation.

positive_intentions,

The app is a active work in progress. I try to make this clear in my post. Any “protocol” being used, is subject to change as I make improvements.

You raise some good points about rotating keys and forward secrecy. These are things I will be including, but the app is far from finished.

Maybe this helps a bit (I know it’s not what you want, but it’s the best I got at the moment without diving into the code): positive-intentions.com/docs/…/authentication/

positive_intentions,

There is a lot to be fixed throughout but file transfer and video calls should be working if you try out the live app.

positive_intentions, (edited )

reddit.com/…/help_me_understand_postquantum_crypt…

Sorry to redirect to Reddit. I’m new to Lemmy.

Tldr; there are several approaches to this issue. In the case of webapps, relying on the offering from the browser should be enough.

I’m also investigating if wasm could also be a way to introduce real-world-entropy to key generation (because I noticed it isn’t possible to seed the browser key generation)

positive_intentions,

Thanks. I want to also investigate if YJS could also fit into the app.

positive_intentions,

Users can selfhost the frontend and backend independently. When creating a profile, you can set it to use your own peerjs-server (set preferences)

The frontend is only run as client-side JavaScript. There isn’t a step to “set up clients”.

positive_intentions,

The project it’s in its early stages. There isn’t anything as formal as a protocol yet. That is also why there isn’t good documentation about it… The best I have for your question is:

positive-intentions.com/docs/…/authentication

positive_intentions,

Thanks. It’s been mentioned before and I’d like to take a look at it when I can make the time.

positive_intentions, (edited )

Sorry. It’s quite buggy.

  • Its best to start off by clearing all site data from the browser settings.
  • Do not have multiple tabs of the app on the same device.
  • It doesnt hurt to refresh to page.

What you’re describing might be related to there being 2 tabs of the app running. This results in both reacting to the new-connection-event, but ultimately resulting in a data conflict.

Plugins shouldn’t be an issue. For stronger security, i have CSP headers to try to prevent browser plugins reading data.

If nothing works then the egg is squarely on my face and my buggy app is too buggy.

positive_intentions,

perhaps.

it started of very vanillajs, but i found that users didnt like the appearance. so i added a faily basic implementation of material ui.

existing frameworks were not compatible with the look, feel and funtionality i was after. i still havent achieved it, but im happy with the progress.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • fightinggames
  • All magazines