Show image uris as actual images inline in messages

[nikolaiwarner]

If we can detect that a uri sent within a message is an image, we should try to show that image inline in the message.

And also have an option to enable/disable the feature.

[masukomi]

given the emphasis on encrypted chats, calling out to an external url to download an image is a potential security risk for people discussing sensitive material. It would expose their IPs and other potential metadata

This could work if there was some "click to load image" type thing.

I think a better solution would be to actually transmit the images via cabal. I don't know much about dat, but It would be good if it could be done similarly to how SSB does it where we can optionally download the blobs. that way folks on low bandwidth connections could still participate in the chat without getting bogged down trying to download an image.

[hackergrrl]

I'd really like it if we had a good p2p blob resolver, so you could post all sorts of things:

• dat://...
• ipfs://...
• ssb://...
• magnet://...

and then it would check if you have/use that p2p network and download it when you'd like it.

If we really want to keep data within the network, we could use a hyperdb trick where each user has a separate "content feed" that they can post binary blobs to. Unlike the main message feed (which is what we use to send chat messages), the content feed would be opt-in: you'd need to explicitly ask for entries in it. This functionality comes for free with hypercore, which cabal is built on.

[cblgh]

+1 i think starting out with the content feed for cabal makes sense. after we have something working we could work on the more general p2p blob resolver module (which would be super rad for many projects in our neck of the woods)

…

Le 18 août 2018 à 01:33, Stephen Whitmore ***@***.***> a écrit : I'd really like it if we had a good p2p blob resolver, so you could post all sorts of things: dat://... ipfs://... ssb://... magnet://... and then it would check if you have/use that p2p network and download it when you'd like it. If we really want to keep data within the network, we could use a hyperdb trick where each user has a separate "content feed" that they can post binary blobs to. Unlike the main message feed (which is what we use to send chat messages), the content feed would be opt-in: you'd need to explicitly ask for entries in it. This functionality comes for free with hypercore, which cabal is built on. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[todrobbins]

Related: #14

See also: https://github.com/cabal-club/cabal-desktop-mini/tree/files, which addresses this feature request by creating a dat archive for shared files. I agree that having a toggle to hide the embeds would be necessary, especially to hide flashy GIFs, etc.

[warcode]

As someone who only cares about the confidentiality of message content and not metadata, and only would hang out with friends, optional direct content embeds seems like it would be a good idea? At least until whatever perfect solution is planned can be implemented.

[cblgh]

You’re right, that could be something people could toggle on in the settings.

…

On 12 Jan 2021, at 16:58, warcode ***@***.***> wrote: As someone who only cares about the confidentiality of message content and not metadata, and only would hang out with friends, optional direct content embeds seems like it would be a good idea? At least until whatever perfect solution is planned can be implemented. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[cblgh]

@khubo raises the excellent idea of using @RangerMauve's p2p-fetch for allowing cross-protocol fetching of images 🧠🤯

[RangerMauve]

If you use electron you can integrate it into the protocol handlers so you could just put urls into the src attribute. :o

[cblgh]

@RangerMauve we do use electron! have you done that in agregore somewhere?

[hackergrrl]

great idea @RangerMauve on p2p-fetch! it'd be great to build this out to support fetching and publishing of {dat,ipfs,hypercore,etc}

[RangerMauve]

I have some code for converting fetch interfaces to protocol handlers for Electron here: https://github.com/AgregoreWeb/agregore-browser/blob/master/app/protocols/fetch-to-handler.js

I combine that with dat-fetch here: https://github.com/AgregoreWeb/agregore-browser/blob/master/app/protocols/hyper-protocol.js

And with ipfs-fetch here: https://github.com/AgregoreWeb/agregore-browser/blob/master/app/protocols/ipfs-protocol.js

I register the handlers on the electron session here: https://github.com/AgregoreWeb/agregore-browser/blob/master/app/protocols/index.js#L72

With those in place you can use the fetch() API in the electron side with the protocols without needing to bundle extra libraries, and any image or video src tags will automatically work with hyper:// and ipfs:// URLs.

Yeah, I'd like to work on p2p-fetch a bit more soon 😁

There's a bug in Electron 11 where the response headers aren't properly available for custom protocols, but that might still work in electron 9 or whatever this is using.