Thanks. I've com across it before. You can find the corresponding security audit online.
Ive tried to address those concerns and I try to give details about it here: https://lemmy.ml/post/18497337
Thanks for the tip. WebRTC is using aes-128, I see in my code I'm using RSA. It sounds like a good idea like to create a cascading cypher with aes-256 which seems to be regarded as "military grade" (but it seems there is no official spec definition for this).
im aiming to make a chat app secure as theorhetically possible as a webapp. for transparency its open source. id like the experience to be as close to possible to a regular chat app. its important to note; there are limitation with p2p and webapps such that messages cant be sent if the peer isnt connected.
to keep this post brief, please take a look at the readme. it has all the information and links.
i dont think its ready to replace any app or service, but id love to get feedback on what you think would make it so you would use it more than once.
im aiming to make a chat app secure as theorhetically possible as a webapp. for transparency its open source. id like the user experience to be as close to possible to a regular chat app. its important to note; there are limitation with p2p and webapps such that messages cant be sent if the peer isnt connected.
to keep this post brief, please take a look at the readme. it has all the information and links.
i dont think its ready to replace any app or service, but id love to get feedback on what you think would make it so you would use it more than once.
i added a section in the contact details page for validating public keys hash.
the experience could be improved in several ways with things like qrcodes, but for now, i think its a nice addition.
i will try set aside some time for proverif. im also investigating what is needed for CISA certification. even without the certification it'll be interesting to see what i can do to security audit my own code (even though it looks like without and objective observer, the assessment isnt valid... but i could share it and someone else could say it looks good. and the overhead for them to assess my app could be less)
here are my thoughts on a possible approach.
it seems the concerns center around validating the keys.
solution 1 (generate new keys):
- i could add a functionality for regenerating keys.
- add functionality for exchanging the keys in various ways (qr, email, text, nfc)
- the remote peer app can import this file and update the contact's keys.
solution 2 (validate keys):
- A generates hash of B's public key
- A sends a link to B (through some trusted medium)
- link opens app validation page with the public key hash encoded in the url
- B generates hash of own public key (related to A)
- B is displayed "success response" if the hash is valid.
- (and vice-versa if wanted)
Spend some time trying to break your own system
i sure try, but im sure i've developed a bias about it being secure and so i might not be seeing all the possible scenarios. this is why feedback is important for me at this stage of development.
thanks for the link to that spec. it looks like it would be pretty unique between applications that have this type of spec. can you tell me what that kind of document is called?
i was recently pointed to something called ProVerif it seems to have a way of describing an implementation and it has some functionality to validate/detect security risks. ive only just come across it and and while it sounds too good to be true, it looks appropriately complicated. do you have any thought on it (or other tools like that)?
thanks!
i understand. can you help me understand what i can do for this. id appriciate if you could critique my approach:
im putting all the weight of the initial exchange being secure on the cryptographically random ID. if you can exchange that on a channel that is secure (whatsapp?/qr-code?/sms?), then the initial connection will establish the keys. the mitm there could be the peerjs-server (or even your ISP), but because the ID is crypto random, it would not be possible to predict who is who. (of course it could be logging connections and IP's and figuring out from other metadata, but if that's a concern, then you should selfhost a peerjs-server).
i previsously created something for sharing files by QR codes as described here. to enhance security more for when peers are together to exchange keys, ive taken that qr-code investigation further to create something that is able to transfer encryption keys fully offline.
a way for users to validate each others public keys
sorry for diving into the code here i dont expect you to start debugging my spaghetti code but to try and explain, let me point you to how i validate public keys. in the file found here around line 96 is what happens on an initial connection. it might not be clear, but i do something like:
- generate a crypto random hash locally
- send that to a peer (encrypted with their public key)
- the peer decrypts using they own private key
- they then send back that same random hash encrypted with my public key.
- decrypt using my private key
i would also like to make an update to check the that the keys are signed (not sure about the terminology, but it was suggested that is a better way to do this validation... will all the redundency i have going on, im not against doing both if its seamless to the user). (note: all peers get a new set of keys generated).
the app is basically a static bundle GUI for peerjs-server. by default it is using the officialy peerjs-server. this is to make it easier for users to get started. it is possible to host your own instance and configure to use it within the app. the frontend is decentralised in the sense it can be selfhosted. and data is only stored locally on your device on your browser. no registration database.
im also investigating options for establishing a webrtc connection with no backend using QR codes to exchange the connection data. this is working but not refined enough to roll out into the app. its something i want to address in the p2p microfrontend i mentioned earlier with the todo-list.
there is no federation with peerjs-server and so peers you connect to will have to be on the same server. for those cases you will have to connect to the same server which is why it makes sense to have a the official peerjs-server as the default. it is only used for brokering a webrtc connection after which connections are P2P.
Less code/complexity is less chance for bugs
completely agree. im breaking the app into smaller chunks (in the form of microfronends). i created a bare-minimum example of p2p communication and state management and framed it as a "todo list" app as can be seen here: https://p2p.positive-intentions.com/?path=/docs/demo-todo-list--docs . it doesnt have the bell and whistles of redundent browser cryptography. it isnt open source or anywhere near finished.
i am going in the direction of developing this further into basic chat functionality. the aim is that this new module will replace what is seen in the chat app. which i expect at that point will be a lot less complex than the one used in the app and with all the features like unit tests and documentation expected in quality work.
in the URL shared, that value is a cryptographically random value used as an ID for the peerjs-server. its best you dont share that publicly (like in your comment) because it undermines it being cryptographically random (the aim is to make it unguessable). i guess its like a phone number (i would suggest you clear all site data from your browser before continuing... you dont want strangers to connect.).
the way it works is that the unguessable ID is first used to connect peers. then on that initial connection, additional keys are created for the extra encryption. if in the future your ID is compromised people wont be able to impersonate you because messages to/from known-peers would be encrypted using that extra layer of encryption.
your feedback is appriciated. im not hurt at all i hope my tone doesnt suggest otherwise. i hope im not coming across an confrontational. i simply have answers and observations at this point which have developed from concerns ive heard before (yours included)... its the nature of learning and developing opinions.
i (perhaps naively) think have created a secure chat app and now it seems to be a matter of convincing others to gain traction. as you might be able to understand i have a bias on the implementation. it was unexpected for me to observe that open sourcing is worth less than paying for someone approval. going in that direction also means, every new PR would also needs to be security assessed.
while $50k can be ridiculous, ive been talking about my app long enough to know paying $1k will result in people questioning the quality of the review and could even work against me by being like i didnt spend anything at all. it seems like a false economy for a project like mine which i cant grow because i cant get funding.
open sourcing the project was done in the interest of the kerkhof-principle and would enable me to better ask for security audits from people who wanted to contribute to open source projects... but no luck. i think i made a reasonable attempt at asking and any more could be seen an spam (which could get me blocked from subreddits). https://www.reddit.com/user/Accurate-Screen8774/search/?q=audit&type=link&cId=4a3bc9d3-7b38-40da-a587-03b2f8ee65e5&iId=4d8c2619-3f64-4885-b360-cb804ddc7854
ultimately, i enjoy working on the project and have several ideas i want to try out so i will continue working on it with wording throughout about it being and "unstable experimental proof-of-concept" so as to not lead anyone to believe it is tried and tested by security professionals, which i think is an appropriate tradeoff.
Why are you adding an additional layer of complexity to webrtc? It has e2ee already?
the app is more "research + development" than "a product". i started of with a webrtc chat app without the additional encryption and it worked like it does now. i wanted to explore some of the browser based functionalities for encryption and to my surprise, it seems fairly performant so i kept it in. it is a redundent layer of encryption and as long as it doesnt compromize the security or privacy, i dont see why not. similarly, im also investigating the cryptography capabilities from WASM.
How does a user validate that they are actually e2ee?
this is where the redundent layer of encryption shines. while webrtc has e2ee, using the browser crytography functions i can generate and exchange keys using the diffie-helman method and ensuring that the message can only be decrypted with the corresponding public-key. something i cant easily verify with webrtc, im just told that its there and it works.
Could a malicious server pretend to support your protocol and decrypt everything?
messages can only be decrypted using the public key exchanged after the initial connection (where those keys are generated and stored for future use). malicious actors will exist in any case and so while i think the app is secure for the majority of cases, here is a section where i have suggestions on enhacing your security. (hint: it relies of you being sensible with how you use the app and not connecting to people you dont trust.)
your view is understandable. security audits can provide confirmation on implementation, especially in sensitive cases relating to security and privacy. this would enable security professionals experts in the field that the implementation is sound.
considered insecure until that point
caution is something i try to encourage in my wording throughout the app, docs, posts. (including this post)
i cant help but think that you might be putting more weight on a security audit than appropriate considering it seems to be prohibitively expensive ($50k). this is simply not something a normal person has expenses for on their sideproject especially for a project that doesnt make money. i have tried to raise funds through things like donations. i think its optimistic for me to see $5 in donation. $50k is simply not happening.
https://github.com/positive-intentions/chat
Is this a secure messaging app? probably not... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?
im not an expert on cyber security or cryptography. im sure there are many gaps in my knowlege in this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels). the algorithms are fairly easy to use and interchangable as described here.
- i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
- another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free (instructions are provided in the readme). im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
- to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
- i received feedback the Signal/Simplex protocol is great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add handlers for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it's simplicity could be a security feature.
- the key detail that makes this approach unique, is because as a webapp, unlike other solutions, users have a choice of using any device/os/browser.
i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the backend to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work. i contacted "Trail of bits" because of their work on SimpleX and they have quoted me $50,000. the best i can offer is "open-source and communicating on reddit". (note: i asked them if i can share those details... summarized response: the SOW is confidential, but i can share the quote.)
while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
(note: this app is an unstable, experiment, proof of concept and not ready to replace any other app or service. It's far from finished and provided for testing and demo purposes only.)
- Github: positive-intentions/chat
- More information about the app: positive-intentions.com
- Follow the subreddit: r/positive\_intentions
https://github.com/positive-intentions/chat
im working on a decentralized chat app similar to Simplex with the additional detail that it's mainly presented as a webapp. Simplex recently posted on their subreddit about "somone else" having registered and hosted a copy of thier website/app.
this could be for something like phishing and they correctly notified people and reccommend to not download from there.
https://www.reddit.com/r/SimpleXChat/comments/1epuf5w/please\_note\_we\_do\_not\_own\_the\_domain/
im now thinking i should point people to my github repository. (the links to the webapp and builds for ios/andoid/ desktop can be found directly there from the readme)... similar to a "domain", im sure its easy enough to create a new github organization and repo that looks similar to the one i already have.
i added a section in the readme about improving the security of the app by using a selfhosted version for those that want/need hightened security/privacy.
Simplex also mention they submitted a complaint to the domain registrar. id like help to learn about what other things i could do if somthing similar happens to my app. this is something that id like to know more about because its seems inevitable to happen (if it becomes popular) given my app is open source and easy to selfhost.
https://youtu.be/2gTTu4OqoiM
https://github.com/positive-intentions/chat
the code related to the video is a faily basic implementation using BabylonJS. it can be found here.
id like to see if i can get handpose-estimation to work well enough to be able to add to the BabylonJS render engine.
im working on something i hope will work like the 8thwall demo here. i couldnt find an open-source alternative to this. my progress so far is as described here. i dont have much experience in creating games or graphics, so any guidance/help/advice is appriciated.
disclaimer: its a proof-of-concept app. for testing and demo purposes only. maybe this article helps clarify some details.
thanks! i'll make a note of that to add. it looks reletively simple to implement in JS, i'll need to check more about browser compatability. tls 1.3 is already in use. i otherwise have wording throughout that users must trust who they connect to.
as for browser extensions, there are CSP headers set to prevent them from accessing personal details.
impossible to update the software
considering the app amounts to a bunch of statics. they wint update themselves if you dont want it to. the app works in many different forms because all form factors can have nuanced security details. its better for security that if people have the ability to selfhost, then they also have the option to choose the form-factor they use based on their preferences.
All nice ideas! I'll take a note. I'd like to make time to make it so on each initial connection it generates new keys too. This should be what I think is forward-secrecy. (Let me know if I'm wrong.)
I don't know the specifics of VPN and it's implication with webrtc, I tried testing and sharing my observations here. I'm open to advice here.
You asked about native builds... Tbh I don't know much about it. I did a short search-engine search and these seem to be well regarded. (Currently?) As a pwa I have a lot of flexibility in the apps form-factor. I was thinking about how easy it would be to make it into a browser extension. (It's not about it being useful, but just providing that extra option.)
I think for my app to be regarded well in security I think it's important for people to use their own instances. The "live app" as I call it is an experimental proof of concept. I wondering about the idea that the app is run on your own forks, but occasionally sync from upstream. As it stands my app is too garbage for anyone to want a copy, but that should eliminate those concerns.
It's also an offline first pwa. Right now it fetches the latest version, but I don't see why I can't create a toggle on the UI to not fetch if there is cache... Again the app is unstable and experimental. I'm working on fixes and improvements as I see it to make a better app. It's a while away from being able to advocate selfhosting to users. But in theory it could address your concerns?
Many attack vectors still indeed exist. With P2P web tech it seems that this allows for an interesting approach and could help reduce the attack-surface. The app is available for iOS, android and desktop. Let me know if you have more concerns.
My bad. I noticed the ego sometimes inflates which seems to stem for naive confidence.
I have observed pitfalls of other apps like mine. In particular one called crypto cat. I'm sure I can't ever be exhaustive enough in learning from other examples.
Reducing metadata is indeed the goal of security and I think I have it reduced to a level where I can exchange webrtc connection data over QR codes or plain text. The IP is exposed at this point but I think this can be further scrubbed with a VPN. Perhaps this is interesting for you. It the minimum example of establishing a webrtc connection with plain text. Not user friendly, but it work without a peer-broker service. In the app I'd like to frame this around exchanging data over QR code.
As for the bitcoin wallet thing, I would think so if it's well tested and ironed out well. As long as I can facilitate the downloading of the data (for backup) and the data syncing between devices then it would be doing that without registering to any backend. There are countless examples of bitcoin exchanges collapsing and taking people's assets. The same could be said with the quality of security provided by chat app providers.
alas, we circle back around to "javascript is inherently insecure".
especially the ones that run inside web browsers like this one does
i dont think this is a valid assersion. it seems wrapped in vagueness about the attack vector. as a webapp it has to be sandboxed in a browser. any vulnerabilities will be related to that. i often hear about browsers having backdoors (which is possible), but theyd be saying that in a world where their operating system is more likely the attack surface. id like to discuss that as a webapp, (and a suitable security stack), this app is secure. take for example any existing secure app (signal/simplex/whatsapp?). they can have all the required bells and whistles for secure/private functionality. but all that encryption can be undermined if a typical low-end phone+os is more than capable of snooping your screen. the same as would apply for my app running in a browser. my arguament is if you dont trust google, you shouldnt use chrome. with a lot of those native offering, your choice is limited to something like apple or android.
this app is also contains builds for iOS, Android and desktop. i dont promote them because im simply not convinced that these native builds are better than what web-technology can provide. a recurring concern is the reliablity of the statics served... it seems thats easy to eliminate if i make it open source and selfhostable. it puts me at a competative disadvantage, but consequently it is unparalelled in the devices it can run on.
APT are a valid concern as any. if this is something youre worried about, i think using this app with a trusted VPN in combination to using disposable profiles, it should be easy to achieve. the mitigation for APT seems simple if that is a concern, but let me know if im overlooking something. webrtc can leak ip addresses and after investigating this, i think you can achieve a reasonable degree of "hiding your personal IP address" based on the information here.
compared with dedicated solutions
the purpose of this project is to create a secure chat app. i want this app to be one of those 'dedicated solutions'. as it stands, its created by a baboon sat in front of chatgpt. but the goal is indeed to create something with unparalelled security. people always seems to avert the idea of this app being secure on the grounds that its JS, but i havent come across any credible way to undermine its security without having compromised the stack above the app (browser/os/peer/network) if any of those are a concern, the app is presented in various distributions from website to native builds.
i hope im not coming across as stubborn here. i really think this app represents a different paradigm in security that nobody is exploring. i dont think ive noticed any lack of interest in decentralized or p2p technology, but nobody seems to be working on this kind of app as a webapp. i find that its not only possible, but i think its relatively trivial to get basic functionality together. i understand that the user-experience isnt great at the moment and will limit the people who want to use it, but on the security grounds alone, i think i could be a real-contender for secure chat.
You conern is well placed. This is why the project has to be open source and I encourage selfhosters.
If this is your concern, I think the offering from other apps is much more shady. While many projects are open source, when provided from an app store you have much less ability to verify the binaries involved match the available source code. It's at this point backdoors can be introduced. (It may be noteworthy that my app serves code unminified for transparency)
As it stands for me app. It's unstable and so I suggest always using the latest version because I will be adding fixes. It is an offline-first pwa. It's possible to make it so it doesn't fetch statics if it already has a cached vopy. At this early stage it doesn't make sense to use this feature because the project is unstable and recieving various fixes and improvements throughout. (There is no audited version of the app.)
As organizations become bigger, I think they can get a better marketing team. The main heavyweight in chat-apps is whatsapp. I think we can agree that it isn't transparent.
Thanks for the advice. I'll try set aside some time for this.
Simplex is good. Mine isn't ready to replace any app or service.
https://github.com/positive-intentions/chat
probably not... Because I'm comparing it to everything... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?
im not an expert on cyber security. im sure there are many gaps in my knowlege in this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman over webrtc (which can be considered secure when exchanged over public channels)
-
i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
-
another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages for free (instructions are provided in the readme). im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
-
to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
-
i received feedback the Signal/Simplex protocol is great, etc. id like to compare that opinion to the observation in how my todo app demo works. (the work is all experimental work-in-progress and far from finished). the demo shows a simple functionality for a basic decentralized todo list. this should already be reasonably secure. i could add a few extra endpoints for exchanging keys diffie-helman style. which at this point is relatively trivial to implement. I think it's simplicity could be a security feature.
-
the key detail that makes this approach unique, is because as a webapp, unlike other solutions, users have a choice of using any device/os/browser.
i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the peerjs-server to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hope you will agree this is true p2p and i hope i can use this as a step towards true privacy and security. security might be further improved by using a trusted VPN.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work.
while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
(note: this app is an unstable, experiment, proof of concept and not ready to replace any other app or service. It's far from finished and provided for testing and demo purposes only. This post is to get feedback on the app to determine if i'm going in the right direction for a secure chat app)
https://github.com/positive-intentions/chat
probably not... but id like to share some details about how my app works so you can tell me what im missing. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify... but i want to understand why?
im not a cyber security expert. im sure there are many gaps in my knowlege of this domain.
using javascript, i created a chat app. it is using peerjs-server to create an encrypted webrtc connection. this is then used to exchange additional encryption keys from cryptography functions built into browsers to add a redundent layer of encryption. the key exchange is done like diffie-helman (which can be considered secure when exchanged over public channels)
-
i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have opened sourced my cryptography module. its basically a thin wrapper around vanilla crypto functions of a browser. a prev post on the matter.
-
another concern for my kind of app (PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for selfhosting. selhosting this app has some unique features. unlike many other selfhosted projects, this app can be hosted on github-pages and instructions are provided. im also working on introducing a way that users can selfhost federated modules. a prev post on the matter.
-
to prevent things like browser extensions, the app uses strict CSP headers to prevent unauthorised code from running. selfhosting users should take note of this when setting up their own instance.
i think if stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the frontend and the peerjs-server to be hosted independently, im on track for creating a chat system with the "fewest moving parts". im hoping this will lead to true p2p and i hope i can use this as a step towards true privacy and security.
i created a threat-model for the app in hopes that i could get a pro-bono security assessment, but understandable the project is too complicated for pro-bono work.
i created a decentralized todo list demo using the p2p framework used in the chat app. this is to demonstrate the bare-minimum functionality of decentralised messaging and state management.
while there are several similar apps out there like mine. i think mine is distinctly a different approach so its hard to find best practices for the functionalities i want to achieve. in particular security practices to use when using p2p technology.
i want to understand more about WebRTC security when using vpn. id like to know if it is more secure with VPN than without… or even if its recommended to use WebRTC with VPN.
i created a webrtc demo: https://chat.positive-intentions.com/#/webrtc (the corresponding code its created with: https://github.com/positive-intentions/chat/blob/staging/src/components/pages/webrtc/WebRTC.jsx)
if i generate a “WebRTC offer” then i see a bunch of information including my IP address.
if i do the same with VPN, i see that my ip address isnt in that payload.
following the information here: https://thehackernews.com/2015/02/webrtc-leaks-vpn-ip-address.html?m=1
and using the demo here: https://ipleak.net/
it seems even with vpn, the local ISP ip seems detected.
a recurring concern ive had on reddit about the security of my app is that webrtc exposes ip addresses. im investigating using the app with vpn. it seems to work like normal.
in the example details given above, i see while the local ISP IP is exposed, the personal ip address is still hidden. im sure what is exposed there is not worthless, but it could help users with privacy and security.
on the back of this investigation id like to see if i can add something like a toggle in my app called “enforce VPN” which will first check to see if you are on a vpn, and if you are, open the rest of the app.
my app is using peerjs-server as the connection broker. this is a third party i have no contractual agreement to provide me with a service. it could help to hide your IP from this service.
![](https://lemmy.ml/pictrs/image/2a4b2a1b-a43f-41b9-8904-878fc423b244.png)
a decentralized P2P todo list app to to demo the P2P framework used in the chat app.
https://github.com/positive-intentions/chat
a wrapper around peerjs. peerjs is good, but it can become complicated to use on complicated projects. This implementation is an attempt to create something like a framework/guideline for decentralized messaging and state management.
https://positive-intentions.github.io/p2p/?path=/story/demo-todo-list--basic
how it works:
- crypto-random ids are generated and used to connect to peerjs-server (to broker a webrtc connection)
- peer1 shares this ID to another browser/tab/person (use the storybook props)
- peers are then automatically connected.
- add todo item
- edit todo item
There are several things here to improve like:
- general cleanup throughout (its early stage for this project and missing all the nice things like good-code and unit-tests)
- adding extra encryption keys for messages comming in and going out (webrtc mandates encryption already)
- handling message callbacks
- key rotation
p2p.positive-intentions.com
github.com/positive-intentions/p2p
a thin wrapper around peerjs with some functionalities for "intuitive" p2p communication.
this is a lighweight version of what is being used in our chat app. it will be developed with the aim to replace what is being used.
this is early development on this and it's missing all the bells-and-whistles seen in the chat app. It's an unstable experimental work-in-progress. it may contain bugs and/or incomplete features. provided for demo and educational purposes only.
Decentralized chat. Contribute to positive-intentions/chat development by creating an account on GitHub.
![](https://lemmy.ml/pictrs/image/99ffef7a-f9d8-4d2f-8595-1620c3735695.png)
in my messaging app, javascript cryptography is the backbone of security so its important for it to be reliable. i would like to introduce you to my decentralized chat app:
https://github.com/positive-intentions/chat
i created thin wrapper around browser-based cryptography functions provided by the browser. it is using webpack 5 module federation to import it at runtime.
https://github.com/positive-intentions/cryptography/blob/staging/src/stories/components/Cryptography.tsx
with this i think i can effectively create encrypted p2p, which i hope to be a step towards true security (but it will take a while to get there).
(note: my app is an experimental unstable proof-of-concept. it is provided for demo and testing purposes.)
chat.positive-intentions.com
https://github.com/positive-intentions/chat
I'm excited to share with you an instant messaging application I've been working on that might interest you. This is a chat app designed to work within your browser, with a focus on browser-based security and decentralization.
What makes this app unique is that it doesn't rely on messaging servers to function. Instead, it works based on your browser's javascript capabilities.
Here are some features of the app:
- Encrypted messaging: Your messages are encrypted, making them more secure.
- File sharing: Easily share files using WebRTC technology and QR codes.
- Voice and video calls: Connect with others through voice and video calls.
- Shared virtual space: Explore a shared mixed-reality space.
- Image board: Browse and share images in a scrollable format.
Your security is a top priority. Here's how the app keeps you safe:
- Decentralized authentication: No central server is required for login, making it harder for anyone to gain unauthorized access.
- Unique IDs: Your ID is cryptographically random, adding an extra layer of security.
- End-to-end encryption: Your messages are encrypted from your device to the recipient's device, ensuring only you and the recipient can read them.
- Local data storage: Your data is stored only on your device, not on any external servers.
- Self-hostable: You have the option to host the app on your own server if you prefer.
A decentralized infrastructure has many unique challenges and this is a unique approach. Ive taken previous feedback and made updates. Its important to note, it is still a work-in-progress and provided for testing/review/feedback purposes.
Looking forward to hearing your thoughts!
Id like to introduce you to a decentralized chat app that works purely in the browser. Breaking away from traditional solutions that require registration and installation.
A decentralized infrastructure has many unique challenges and this is a unique approach. Ive taken previsous feedback and made updates. Its important to note, it is still a work-in-progress and provided for testing/review/feedback purposes. it would be great if you can tell me what you think.
Some of the features of the app include:
- Free
- Decentralised
- No cookies
- P2P encrypted
- No registration
- No installing
- Group messaging
- Text messaging
- Multimedia messaging
- Offline messaging (LAN/hotspot)
- File transfer
- Video calls
- Data-ownership
- Selfhosted (optional)
- Screensharing (on desktop browsers)
- OS notifications (where supported)
With no registration or installation required, its easy to get started.
Id like to introduce you to a decentralized chat app that works purely in the browser. Breaking away from traditional solutions that require registration and installation.
A decentralized infrastructure has many unique challenges and this is a unique approach. Ive taken previsous feedback and made updates. Its important to note, it is still a work-in-progress and provided for testing/review/feedback purposes. it would be great if you can tell me what you think.
Some of the features of the app include:
- Free
- Decentralised
- No cookies
- P2P encrypted
- No registration
- No installing
- Group messaging
- Text messaging
- Multimedia messaging
- Offline messaging (LAN/hotspot)
- File transfer
- Video calls
- Data-ownership
- Selfhosted (optional)
- Screensharing (on desktop browsers)
- OS notifications (where supported)
With no registration or installation required, its easy to get started.
Decentralized chat. Contribute to positive-intentions/chat development by creating an account on GitHub.
![](https://lemmy.ml/pictrs/image/0c4a12d1-9f89-4342-bb5a-ed07b78a64ff.png)
chat.positive-intentions.com
https://github.com/positive-intentions/chat
I'm excited to share with you an instant messaging application I've been working on that might interest you. This is a chat app designed to work within your browser, with a focus on browser-based security and decentralization.
What makes this app unique is that it doesn't rely on messaging servers to function. Instead, it works based on your browser's javascript capabilities, so even low-end devices should work.
Here are some features of the app:
- Encrypted messaging: Your messages are encrypted, making them more secure.
- File sharing: Easily share files using WebRTC technology and QR codes.
- Voice and video calls: Connect with others through voice and video calls.
- Shared virtual space: Explore a shared mixed-reality space.
- Image board: Browse and share images in a scrollable format.
Your security is a top priority. Here's how the app keeps you safe:
- Decentralized authentication: No central server is required for login, making it harder for anyone to gain unauthorized access.
- Unique IDs: Your ID is cryptographically random, adding an extra layer of security.
- End-to-end encryption: Your messages are encrypted from your device to the recipient's device, ensuring only you and the recipient can read them.
- Local data storage: Your data is stored only on your device, not on any external servers.
- Self-hostable: You have the option to host the app on your own server if you prefer.
The app is still in the early stages and I'm exploring what's possible with this technology. I'd love to hear your feedback on the idea and the current state of the app. If you have any feature requests or ideas, I'm all ears in the comments below!
Looking forward to hearing your thoughts!