id like to share some details about how my app works so you can discover/give me feedback on my app. 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.

https://github.com/positive-intentions/chat

https://positive-intentions.com/blog/introducing-decentralized-chat

im not an expert on #cyberSecurity. im sure there are many gaps in my knowlege in this domain.

using #javascript, i initially created a fairly basic #chatApp using using #peerjs to create #encrypted #webrtc #connections. this was then easily enhanced by exchanging additional #encryption #keys from #cryptography functions built into browsers (#webcrypto api) to add a redundent layer of encryption. a #diffieHelman key #exchange is done over #webrtc (which can be considered #secure when exchanged over public channels) to create #serverless #p2p #authentication.

- i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have #openedSource my #cryptography module. its basically a thin wrapper around vanilla cryptography functions of a #browser (webcrypto api).

- 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 #githubPages (instructions are provided in the readme). im also working towards having better support for running the index.html directly without a static server.

- 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. completely undertsandable and agree, but wonder if im reducing the #complexity by working with #webrtc. while it has its many flaws, i think risks can be reasonable mitigated if the #cryptography functions are implemented correctly. (all data out is #encrypted and all data in is #decrypted on-the-fly)

- 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. while a webapp can have nuanced #vulnerabilities, i think by #openSourcing and providing instructions for #selfhosting and instructions to #build for various #platforms, it can provide a reasonable level of #security.

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 #chatSystem with the "fewest moving parts". i 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.

while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find #bestPractices for the functionalities i want to achieve. in particular #security practices to use when using #p2p technology.

(note: this app is an #unstable, #experiment, #proofOfConcept 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 progress to determine if i'm going in the right direction for a secure chat app)

.io domain¹ likely being phased-out² — seven suggested steps

Good article in The Verge summarizing recent .io related events, see that for more context if this is news to you:
* https://www.theverge.com/2024/10/8/24265441/uk-treaty-end-io-domain-chagos-islands

It looks likely .io (and .io domains) will go away in the next few years (as .cs and .yu did³), so here are my suggested steps to take depending on your usage of .io domains:

1. Avoid buying new .io domains (or making plans with existing ones; sell if you can)
2. If you currently run a .io service⁴ (for a company or community), make and publicize a transition plan (like a new domain, redirection, orderly shutdown plan for redirects)
3. If you have a personal site on a .io domain⁵ or subdomain, make your own transition plan, and perhaps post about how others should link to your posts
4. If you are using someone else’s .io domain to publish (like #GitHubPages⁶), make a transition plan to publish elsewhere and leave a forwarding note and link behind
5. If you use a .io domain as your Web sign-in login on any sites, switch them to another non-io personal domain
6. Similarly if your site accepts #WebSignIn logins (via #IndieAuth, #RelMeAuth, or even #OpenID), consider discouraging any new sign-ups from .io domains, and warning any existing users with .io domains to switch per # 5
7. If you have posts (or a whole #indieweb site) with links to .io sites or pages (like those in 2-4 above), make a plan for editing those links to point to an alternative or an archival copy (like on the Internet Archive)

And of course, post about your #dotIO plans.

Glossary

Domain
 https://indieweb.org/domain
IndieAuth
 https://indieweb.org/IndieAuth
Internet Archive
 https://web.archive.org/
OpenID
 https://indieweb.org/OpenID
Redirect
 https://indieweb.org/redirect
RelMeAuth
 https://indieweb.org/RelMeAuth
Web sign-in
 https://indieweb.org/Web_sign-in


References:

¹ https://indieweb.org/.io
² https://en.wikipedia.org/wiki/.io#Phasing_Out
³ https://en.wikipedia.org/wiki/.cs
⁴ E.g. https://indieweb.org/webmention.io or https://indieweb.org/granary.io
⁵ E.g. https://indieweb.org/werd.io
⁶ https://indieweb.org/github.io


This is post 25 of #100PostsOfIndieWeb. #100Posts

← https://tantek.com/2024/283/t1/metaphors-constructive-cooperative-joyful
→