Feature Idea: HTTP tunneling through Jami, for social IoT, remote tech support, and profile pages
Personal websites, in my opinion, were the defining element that really made the early web great. Sadly, they have almost been driven to nonexistence by social media, which on many sites does not truly allow any level of expression beyond a news feed.
Use Cases
Current IoT devices can often have some kind of social aspect, such as sharing fitness data, and at the very least usually need some way to access them remotely, which is currently almost exclusively the domain of centralized services.
Many times, one also wants to give control of a local service to a remote user, for tech support purposes as in TeamViewer, and quite often one wants to share a file with a group on a "Pull" basis, rather than directly sending to one person.
In cases of censorship, or off-grid scenarios where only one person has real internet access, one might also want to share access to a public internet resource, to a few specific users only.
Applications like Kiwix that serve offline copies of things like Wikipedia could provide trusted educational content over an entire mesh network.
The system could be used for remote access to NextCloud and similar.
More... Ahem... Personal devices are apparently becoming cloud IoT enabled, and there was just a big controversy or something in the news, and I would imagine that's one area where you would really want to control exactly who has access.
Profile pages with images are a staple of social media, and are especially useful if you make a dedicated account for a certain project.
A secure and decentralized association between a server and your account allows you to integrate seamlessly with other decentralized projects, some of which could eventually have deeper integration, without Jami needing to specifically support them.
Similar to images and locations, any arbitrary dynamic content could be shared with other users in a chat, like live webcam views, or perhaps even embedded directly inline into a chat window in an iframe.
Implementation
One possibility that would seem to cover all of these use cases with minimal overhead is HTTP tunneling. Jami could expose an unlimited number of HTTP/WebSocket services per account, each with a freely assignable name.
These services would then be available via Jami acting as a proxy, on any other device, at SERVICENAME.USERID.localhost:someport. As completely separate subdomains, all sandboxing and security is provided by the browser.
SERVICENAME is never sent or advertised in the cleartext at any point, and the UI for creating tunnels defaults to a long random name, making them equivalent to capability URLs unless changed to short public URLs purposefully.
An API is added via DBus or Android Intents, to allow other apps to easily specify the tunnel they want to create.
Services can have expiration dates on them, so that you do not forget to delete one you only meant to share briefly. Expired services are completely deleted if not refreshed, preventing any risk of reusing a capability URL that you meant to only share for one session.
Profile Pages
One could define the empty service name(Just USERID.localhost) as a public profile page, with a 32KB limit or such, that syncs across accounts and caches on other nodes on a most-recent-wins basis. Maybe you could even store it directly in the DHT, digitally signed.
Any additional content or images could then be loaded using the proxy mechanism on a home server, failing gracefully to just this minimal DHT-only content.
Prior Art
Similar proposal in XMPP: https://xmpp.org/extensions/xep-0332.html
Data forms in XMPP cover similar use cases: https://xmpp.org/extensions/xep-0004.html
Now abandoned Mozilla proposal for IoT on LAN: https://wiki.mozilla.org/FlyWeb
Nabu Casa seems to use the same embedded key in subdomain concept as this, albeit on a centralized remote server, to access Home Assistant via the cloud: https://www.nabucasa.com/config/remote/
Security Issues
IP-revealing Privacy issue for profile pages and inline chat content
Profile pages could use tracking pixels and the like, breaking I2P et al. But we are proxying everything through localhost, and so we can use the content-security-policy to stop this.
This does not stop WebRTC exfiltration from leaking your IP, but the entire profile can be wrapped in an iframe that disables JS entirely, and inline chat content can be hidden behind a "Do you want to load this content? It may include resources from an external server" popup.
For anything but profile pages, any privacy issues are going to be up to the user, as with any other site.
Ideally profiles would be served in an embedded WebView anyway, giving another place to further enforce no-js behavior.