Thanks!

It sounds promising if you chose it for a similar reason.

I’ll plan something and see if I can get all the core parts working.

Thanks. I’m a JavaScript developer. To create a webapp is relatively easy for me because I’m familiar with the tooling.

I see there are things like UI component libraries like dioxus-material… I suspect there will be things I might have to create myself. Are there nuances that might stand out?

What are your thoughts on the ecosystem with dioxus?

My core reason to consider dioxus over JavaScript is the ability to use more mature tooling for formal verification.

Those are useful hooks for their own purpose. My approach might be more comparable to redux.

In contrast to redux, in this approach, we can update a state value and all other components listening will receive and update accordingly. Redux does this in a deterministic render and compares the vdom for what to update.

The origins on my approach is from trying to create it for webcomponents where components between different shadow-roots need to share an update.

all understandable questions.

group messaging

this is very complex as im sure you can imagine. im using a p2p and the approach im using is that a “group” is basically a “room with ID”. when sending a message to a group, you send the message to the peers individually and they know to store the payload within the context of the “room with ID”. scaling something like that is limited by how many webrtc connections are possible by the hardware.

i have some research relating to using MLS, but without some central store to keep the mls keys per-epoch, its very unstable as peers can go offline unexpectedly. another approach im investigating is to be able to ping connected peers to create a kind of mesh-graph that i could use to relay messages. this approach could also be better resiliant to peers going offline in the sense, that the graph could heal from peers going offline.

im sure there are many details i havent considered, but i have buggy group messaging on the WIP version here: https://enkrypted.chat/ (go to chat-thread page > 3-dot menu on top-right > invite peer)

offline delivery

ive mulled over it enough to at least try using an approach to use git as a CRDT. it seems overkill for application data, but it would also allow use git as an offline message cache. https://programming.dev/post/51866250 . i havent implemented anything for this yet. im still mulling it over to make sure i dont overlook important details.

alternative networks

webrtc isnt the bit that make this app secure, its the local-first. no need to register anywhere when you have local-first crypto-random IDs. im open to considering other networks. tor has limitations around webrtc. this is perhaps where the git-based offline cache can come in useful in a tor network. i2p is also good as are many others like nostr. i’ll see what setup works best. i think it would be great to be able to support multiple.

if you want to know more about “how it works”, you can take a look at the roadmap here: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown

feel free to reach out for clarity instead of reading all that.

thanks. ive had that feedback before. its also not the easiest thing to type out. many are probably unable to find it again because the name wasnt memorable enough.

im in the process of rebranding to “http://enkrypted.chat/”. talking about it to others could still lead to some confusion, but i think could be a bit more memorable to say “encrypted.chat, but with a ‘K’.”

I’ve come across it before. That one is good and easy to get started.

I also have another version to the approach where im refining details: https://enkrypted.chat/ . (It’s far from finished and not open source yet.)

Thanks! I haven’t come across chatmail before. I’ll take a look there and see how it works.

With git, I like that there are many providers with a free-tier. It’ll make it easier to get started. Although it seems this way of using git could be against ToS.

Ideally I can advise people to self-host. I’m hoping to make something generic so it it can work with any git backend lit gitlab, codeberg, etc.

thanks. i’ll aim to do that. i’ll see if i can figure out who to reach out to from github and etc to ask.

feel free to reach out. im reluctant to waste your time on reading through all that draft. its fairly unique and more going against the grain… not typically a good sign.

my project is far from finished including all the spec and docs.

That’s right. Git as an offline cache. When you read a peers message, you can also update you own git repo to say you read it, and so when the peer comes online they can update their side to delete the messages (keeping the size small)… Going further against the grain, the app doesn’t care about the history of messages deleted, so I expect to add things for purging history.

I considered the Blockchain, but i think the git approach is better. It’s hard to describe what I’m imagining. I’d like to put together a demo when I get time.

I have a full-ish description of the protocol.

https://positive-intentions.com/docs/technical/whitepaper/complete-protocol-spec

Instead of reading that, if you really want to know more, I would suggest you ask me for clarity. (Nothing about this git approach is mentioned there.)

In my app I’m aiming for minimal steps to get started. The frontend is a pwa which works out the box as a webapp.

There is a focus on local-first storage. When connected over webrtc, no backend storage is needed.

This approach with git would be optional. Users have frequently asked about the ability to send messages offline (a completely normal expectation for messaging app). It seemed like a hard limit until this idea with git. My app works without this feature, but with nuanced tradeoffs.

If I host a git-sever myself, but that would be centralising my project.

In any case it wouldn’t be on my account. It would be great for users to self-host. Things like GitHub would only make it easier to get started to test things out.

Why would they ban my account? That would be unsettling. I’m a developer. The code itself is fairly basic git stuff.

My project is hardly popular, but if it gets there, I’m sure it would impact githubs performance. Would the concern be that my app ddos GitHub? I can explicitly prevent remotes like GitHub if necessary.

I’m happy to advise people to self-host a git server. That would be ideal. The ability to do it on GitHub or codeberg would only make it easier to get started. I can put logic there to prevent using a remote with from GitHub if necessary.

In any case, it wouldn’t be on my git account.

This is all ultimately for my project which is a fairly unique approach to secure messaging. I’m trying things out.

That would be acceptable. I can limit it to only text messages.

The aim would be for it to be able to use a generic git backend. Perhaps the advice I give should be to self-host a git server.

i understand how it must sound but ive thought about it for a while, and it seems ideal for my particular architecture.

github isnt decentralized, but git can have multiple remotes for redundency. you could use multiple providers including selfhosted options.

that “can” is all i need to know/confirm. im not using git in a conventional way at all.

it’ll be unfortunate if github pulls the plug on my app. a key detail about git is that its decentralised. users can use different providers like gitlab (many have a free offering). git itself can have multiple remotes for redundency.

in my project there is a focus on client-side storage. i hope it doesnt ever get to 10GB. as messages are published/read, the git DB is cleared as appropriate. i dont need the git history so i’ll do what is needed to reduce the data consumed. i dont expect it to get to that 10GB capacity, that isnt its purpose and thats a bridge i dont exprect to cross any time soon.

your absolute right about there being alternative ways to do this. i specifically want some thing a user can manage. my app right now doesnt have offline-capabilities and this is an approach to introducing that capability. using a http server would be centralizing an otherwise decentralised architecture.

i have given it some thought and i think this is the only way it makes sense for me to introduce offline messaging without centralizing.

the project is pretty complicated and its difficult to describe how it would work without an exampler so id like to share the initial idea here before i try things out to demo.

in this scenario, users would be creating some empty git repo to read/write to. it would be great if it isnt breaking the rules… but if it does, by using git, it would be easy enough to switch to another git provider (including selfhosted options).

Thats cool! I haven’t seen that before.

My approach is because I specifically wanted the react DX… This would then make it easier to refactor my existing projects.

With AI, “easier” is a relative term. I wanted something that remains intuitive to work with.