Try Contact me on Delta Chat:
I think to join a group, the members already have to be in your contacts⦠itās not letting me add you or join based on your id, as far as I can tell. I generated a group also with id
Do you see a way to join the group?
Just cut and paste after hitting the plus sign bottom right, thatās how I added southside to the contacts list in the delta chat appā¦
@Southside @Helen the key capability tech behind the RT for ref.
webxdc Join Realtime Channel Capabilities
The webxdc app that uses the joinRealtimeChannel()
API provides real-time communication capabilities. This API allows the app to join a real-time channel, enabling instant data exchange and synchronization between multiple users. This feature enhances interactivity and collaboration within the chat environment, making it suitable for applications that require live updates and shared experiences, such as collaborative document editing or real-time games.
webxdc.org
webxdc - web apps shared in a chat
github.com
GitHub - webxdc/webxdc-dev: A development server for webxdc apps
support.delta.chat
Your ideas for new webxdc apps? - #16 by link2xt - webxdc - Delta.Chat
webxdc.org
webxdc apps
github.com
webxdc Ā· GitHub
to speed things along here important read @Southside @Helen
Could explain why I couldnāt add @Southside : āOur iOS app is a self-development using UIKit and Swift bindings to core. It is the youngest sibling in our offerings and also needs more love.ā
Iām having bother with getting my Android phone to work yet.
But I have an ongoing issue with wifi devices and wired devices not always talking to each other despite being on the same /24 subnet.
Iām calling it a local issue for now.
Potential Webxdc security concerns?
A privacy note on IP-addresses
Delta Chat does not store IP-addresses anywhere and it does not expose IP addresses in the user interface or to webxdc apps. Iroh relay servers do not see all the IP addresses that user devices advertise to each other (for example relays donāt see peerās WLAN addresses), and relays also do not store any IP addresses when facilitating a P2P connection.
However, chat partners may learn about your IP address if they deploy some network monitoring tool or use a modified version of Delta Chat. If using webxdc apps with a potentially hostile chat partner is a concern for you you may disable the āwebxdc realtimeā setting in āadvanced settingsā to be sure that Delta Chat will never attempt any Peer-to-Peer connection with anyone. Donāt forget to then also be careful when clicking on any HTTPS-link in a chat as a hostile sender could use it to extract your IP-address as well.
From:
Well for native mail it would likely use the pointer and the sender adds a pointer to your mail queue. Your apps processes that.
For moving mail in and out then it would just access the current mail system since that delivers just fine now. So you have your current email service and the apps accesses that. No need for autonomi to duplicate that. Maybe current mail servers will eventually incorporate autonomi and send autonomi addressed mail sent from a email app to the autonomi address directly.
On the speed issue, Iām finding the performance fairly good with a bit of caching.
The latest incarnation of IMIM with sn_httpd is pretty useable: I AM IMMUTABLE! Blogging with IMIM
Being able to cache archive listings and app config in sn_httpd, while using etags to ensure immutable content is heavily cached in the browser makes it relatively snappy.
For IMIM, once the blog listing has been loaded, it has already retrieved and cached the articles and the typescript doesnāt need reloading as it is a single page app too.
Iād encourage folks to try it, using a local sn_httpd container/instance to see what you think. I find it quite usable!
@Southside @Helen my test deltachat ID is now this dv17torbc@nine.testrun.org I blew up the other connection by mistakeā¦
Okay, I will try adding you on a different device soon. Still no luck on iOSā¦
I am not sure if I have understood you correctly, do you mean a mail connection between the clearnet and the Autonomi network? I donāt know if there should be such a thing at all because currently mail servers send and receive messages based on a timestamp, whereas in Autonomi timestamps do not exist according to SafeNet principles, which would mean that a message should be validated according to the network rules (considered sent or received).
Shouldnāt we stick to the principle that better is the enemy of worse?
Some more positive news for autonomi performance: Discord
Tldr; download speeds in sn_httpd with no caching are currently between 500ms and 1500ms. That compares well with BBC News website at only 3x faster at 150ms to 650ms with a quick test under same conditions.
Whatever people want to write into an app.
The no time is for the protocols and nodes. Does not mean that timestamps are forbidden in autonomi world. Its that the node protocols do not use time in its workings. BUT having said that they still use timeouts, timing of responses, just the protocol do not use time of day for anything. IE just local timing.
Time for mail is needed for normal world and should exist in autonomi mail. Will time determine order in the mail queue, then I agree that it should not, but that is also the case in email systems, the order of receipt is the way its stored. email programs can sort your emails on time or sender or ⦠IE mail would use local time of day of the sender and receiver.
I do think it would be a great good thing to have email/messaging within Autonomi. Iām sure there will be all kinds of dapps and dadaptations (new word!) once the API is available, but if email and messaging (and ?) is built into Autonomiās capabilities⦠if we build it⦠they will come.
Certainly Autonomi should have an a-mail that would be an integral part of the communication system, but I am not in favour of combining the Autonomi network with the current Internet, also for security reasons. I believe that access to āpremiumā networks is a much healthier approach to the development of network (make the effort, attach your device to the network, in return you get time, privacy and security). At the same time, I expect that in the first few years Autonomi will be used mainly by companies and the most knowledgeable users.
Its not actually combining them in the sense they work together.
Its what people are going to do and that is pass data between the two via apps written. We are not going to stop that. Also smpt/imap is its own protocol running across the āinternetā
Combining with existing protocols is also likely to get useful apps to users quicker and drive adoption. We donāt need to reinvent every wheel, just because we can.
For example, we have antcli. It is handy to have. However, it is another interface to learn. It also spins up a new client and establishes a connection every time it is ran.
We do have a stack of existing tools, apps and frameworks that work with HTTP though.
Case in point, we can run `ant file download xor targetā and we are limited to store a file. It is also slow, as it takes 10s of seconds to connect to peers (at least currently).
But⦠wget can grab files via HTTP and pipe them into other apps. Or save them to a file. The HTTP server already has a warm connection. It already has an established caching protocol too. It can stream via websocks also.
So much more flexibility.
As a dev community, I think being smart about what gives us most reach to users is essential for success. While Iād love to see innovative native apps, it may be much harder to establish them. Folks donāt want to throw everything they know and love out. They want painless migration to something that will end up much better.