"attached" url field - Githubissues

earonesty commented 1 year ago

a data url can allow for the embedding of images with mime type:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs

or the embedding of a gif, or podcast link or whatever

a single url field as an "attachment" should be more than enough for all major use cases that people have been discussing

the field can just be named url. the decision as to what to do with the url can be based on the event type (for example, a set_profile event vs a text_note event can use the url for the profile pic vs an embetted pic to go along with the note)

example of an embedded image:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAYAAACqaXHeAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAnWSURBVHhe1ZsJdFTVGce/92YmIcUIIlsgKAbBIjTR2sKRFlxowVoqtEXx0CrVBk5LS6VKe6qn7el6WtRaAZWm2EWPGy0q1K2L1gUKasClVKyxKpywg+xCMst7/f/fvZPMJO/NTObdYfmd8+UuM5l53/e+e+/33XfHkhJzZNGAwSjOh3wMMhTCdl9ID0gUQpKQA5BdkCYtr0HWVMzZugllyTBuAChso/gk5ErIeMgwSBjegyzXsgoGcdhpCmMGgOKnovgmZDokrNJB0Bt+C2mAId73ekIS2gBa8e9D6iEnse8okIDcDpkf1hBFGwCKc/x+G3ITpCf7jgEtkBshd8AQnEe6TFEGgPJno6ArfsLrOPashsyCEd5QzcLhhNUloDzHeSPkeFGejIGsx7XNVM3CKdgD8OExFLdCvuV1HL8shlwHb+A8kZeCDADlK1DcC5nqdRz/PAr5EoxwRDWDyWsArfxSyOe8jhOHv0CuzGeEnHOAdvv7IOaVd11dKRmXQe6DDulo05d8k+B8yBdU1SyREdMl9ulFEhl5lVinDEFP0StyLnjtjBcCCfxWWO7rKO5SLdO4EvvMEokM+axuutL6+zpxjyCmsSNi9awRd8/b6jUz1GMo/E7Xs/D1AChfh+JXqlUKLLEHMD9SuHubxD3MPAgX1LdOyqc/J+X1/5HYhDvFrmIOFZol0Gm4rmfRyQB6zNBanPyKJ8cYt3ufLVZFL90Scba+DJuoS7H7K4WtbqdIZNgUkbKTvXZI6OkNfvOBnwd8DXKeqhaJZUnZ5PslOnqe2IOQGEZhS7c9ibP6natrCmfLv1QFRrMHjVN14iTF2QbjmGEsZLaqtpM1B8BCvVFw8IWK7e0+H5GyaX/VLeCmxNm+TpzmF3C3GyVae63YNRP1axj/fzgHQ2A3/jEq3eoRzZapnMrZ8YrE/4R5QnuHAbgkDsJ80JZAdfzkuZDQiY1d1cGBrAj6Rkl01Dwpm7K0XXngjf1yfiXmhT61bcoTd9s6k8oTDuvvqqqizQP03d8I6e51FA1m+EsaJHJmF0OH+EFxDzSLhfkhTfzxGeJsfFq3jMEQuSrtBZnmnQEJqTyxJPG32RJ/eIok1/wSM/z/dH8eyiqzlCdcAazKgd4wMQiDu7akyfMA3H0agld6BttGcVJS/uWVYvXidmBxpN5aJsnGBeLue1f3hIY7SzXwAiftARdBzCtPENhwAvTFgTcm8+YrEjlrqmfE6HnMxI1wOoT7lm1D4FJdmgfLn93/o7qRTQrju6VhqMSXTZbki/PF2flv/Yo/0fNvlNiFv9Ct0Hyef9IGYOJQEqzu/RHr+7u/u+VFb3w729dKcu1CiS+dKPE/TxJn8yr9js5ERl4tkeHccA6NMgDGfw1KZiMlwQtlERj5kdqsA6A0WPKcHa9K/NGpklr/R93ZmegobkWG5nToPpgewNjT/woNYA9sj/kzYeLjvv9f3eoA4obEc9/DexAc+WBVVqvVITxjaIBzVL0EIAK0q725phMqxM31jMNGRphjCTWTI9TRANmLr0Gs7v0w/s/UrWy88Z/L8fCS1YOTdQAte3QlFMNoAM4BJcHL7AJCWWfXelghyANciYy4SqyTqnQ7G/fgFnE/2K5boRhmYSLgJ/VTbbPExv5YInV8YOQHZv/db8ITVqPcIO6hbQhSD8Nr+op9xgSs/V8MNF7qtQZJrPqJboViFw1wGJVwub8fuLvc2LBOPUt3mIGGan3wYpFWPkwOTQtNzNjYOLyTYcJfP9w9TRJfPs2U8iTq72MGyDX+k68ultS7T2GZK3Aiw9BIPD0Xd3488oF3dKcZeIVFPVTMR9D6z9k7ufrnkniyXlrvHiHxhyZI8uVbxd2f4xxE7EMIfq4Xu/cI3WGMBA1gzJ/aYPxfzR2oznj7f+nZn5Hf7jdggF9L672jJfH3b3gzvB/WyadJ2RVPid1npO4xwgEaQG3HGiTX+He2voS/Pus/or9U03JpvX8ckqLXdWcHEFJHx9/GimqHZwcNYCzJTpNz/c+R6HgkWzxPYBTpB4eBoa1yspFXGRCQFwh3ck+7EEHLAOXadP+aS/SLHcD459qfD4bA7n7uzvlj9TK2tDbRALmT8DxYPQZL2aR7pPwrjZC1Ujb1MYl8+HL9ajbe+M8Z/2uYPcZynLaxI7oSmnU0wPOqXhyR4VfggtTzBmZoudzTyRf/a+zB4708IoigibII1tgVc7Y2o1LcPBDtJpHaa3QjP5FzZ0ls3M8kMvSy9nSWY52bnnpliAy5VGKfWuDVfXGS4m5bqxuheAu6b/JuB8LhhSjmsN4V7L61Ept4lzcMCrmznYgfwt3cLG7LPmge8z7HquChs2Ccjf+Q+GMz1DAJx2IYYHbaADzQWNwGPO4gt734SMuu+riX/1s9izRIAcRXTBOnOc9KUhgXwAAvtF0ljMBhEH5n2DNIlUTH3BQ4GRZLasNDkvjn9aiFNi6P4g7P3BYnS3QZDgQ07uGdGB+ZOZYryZduUU954gd1X9dg7pB4nkcCjXjWA1SelUwDLIIcUtWQMDbIyAXcve8g3L1N4o9fjWwOq0YmiQ/whuClkU+WEs/cgNxhJqwQ172hwBfKHarawZwYBjej+I5qFQ/DYO4FpElteBCuO8+rR7FqRLESpEk8cY2kmld621925SAv8SFu/ID3JMjd9x4+MPM+hWYh7v51up7lAYTbLHtVtXjsftlPh5227W94RmaShDvvbY4mj3g7xCnM8Km3V3jibHpWZYhmlcdyIz9VVUXWp8MyHAKh95rs6sxDpC4CIJ5kBVDGHjha1YHLrbBC9wTMcDN0zNpr72RevIGnqkJFGqmmRyT1+hLc1TdVXM/9PmD3RirrnQVQeHff7B3OxRrILaraTtC3cycz/1PLAOi+iZU/ktYHLpLWZZPalPRS5IwJr31olBzqMhM3t9PmT+CagglxFooG1TIElLfKeyBoGisWgqZU4+3itu7XL5aUuVDeN77OuajCCDwnyPOCJzL8LUFgmJ9zAOIfearqSdU6IXkYwtAxkILCKnjCMyguVq0Thicgl+MmFn9YOg0+hMnSieQJj0DyKk8KXoPwYTzYa3ZSLA3cNc17TD5NlzMLDAeeJOWXmH+cFg4+4rsBiv9GNQujywYgMALPut4N8T/8c/Rh4HYtlF+vmoVTlAHSwBCcYX8I4c9gjwWM7fmbRf6Q8uj9bC4TGIFHNX4A4dA4Wj+c5KYCQ/YFUPzY/HCyIzBEJQoGHF+FlOrQBXet7oTcE1bxNMYMkAmMwZhhMoTnD/3PyBQOlV4B4br+LBQv4MFC4ZTEAJnAGNUoLoDUQvhIh94R9PP5nRAqzKdVr0DWQeECDxsXg8j/ATnjJMJXpNMwAAAAAElFTkSuQmCC

fiatjaf commented 1 year ago

I don't know if this is a good idea (I think it is not), but, if it is, then we can probably refer to these attachments inside the note content like email attachments?

earonesty commented 1 year ago

i think there's no other good way to publish images. url's won't work because they have to be hosted. putting it in the note content is ok, rendering agents can just know about "data urls" and everything can work fine. but none of them do. maybe all that's needed is a NIP that gives hints as to how to parse and render urls when observed in notes?

the only major downside of embedding image data in the notes is that notes can swiftly become un-human-readable and extremely large. and with limits, agents will be tempted to spam nostr with 50 notes in order to render one very large video, etc. and then everyone will have their own way of breaking up images and we'll have the MMS nightmare

i feel like keeping media "out of band" is a great way to clean up the notes

be cool to be able to grab a note and not reference the media, for example

maybe a new kind of url that refers to another note is a clean way of doing this?

hey check out my image: nostr://<hex-event-id-of-event-containing-image-data>

and then i can filter out media notes easily, archive them easily, and use them to render only if i want to....

the spec can be as simple as this:

given a nostr link, follow the link, get the contents, and whatever the contents are, treat them as if they are the link

fiatjaf commented 1 year ago

Why URLs won't work?

earonesty commented 1 year ago

if i had persistent, quality centralized hosting, why would i use nostr? seems to defeat the purpose, imo. but maybe i'm missing something. i guess it's ok to just tell users that images and media have to be "hosted elsewhere", but without a simple and standard way to embed and if nostr takes off - people will just invent one.

but yeah, i can use a data url, like above... but it really clutters the note right? and leads to comingling the note with the image in one big blob. "internal refs" clean that up, keep notes small and readable

if you paste that data url in the browser it renders fine by the way (no its not rick astley)

fiatjaf commented 1 year ago

The purpose of Nostr is not to replace the internet, although I don't know how to answer your question exactly right now without writing an essay. I think my basic point is that image hosting services do not need the censorship-resistance guarantees that Nostr provides and they are much more efficient than Nostr.

What I expect to happen is that clients that want to offer a good UX will have built-in image hosting providers that users will be able to use seamlessly.

Meanwhile I also expect most relays to block large events as time goes by unless they're being well-paid for that, so the data-url hack will eventually stop working.

vitorpamplona commented 1 year ago

Just encourage IPFS (hashed ids to make sure the content doesn't change) for external data.

There is a point here that external servers can be used to pixel-track the location of users (by IP), including the profile image.

fiatjaf commented 1 year ago

IPFS can be used, yes. Ideally we would just use IPFS for files like that and it would work. In practice IPFS doesn't work, but I don't see a reason why it can't be tried.

Tracking people with images is a problem that clients must solve by themselves. They don't have the obligation to automatically load the image. Email has this problem, other platforms like message boards and instant messaging apps have this problem. Each solves it in their own way.

5hanth commented 1 year ago

A possible NIP to provide a standard method for hosting images, videos, and large files. The NIP will enable the standard of SDKs for clients to conveniently upload files and render them. The following can be a flow:

Each file uploaded to the hosting service will have two parts: <domain-name>/<file-name>
To upload a file to the hosting service, the client should request a signed URL from the hosting service for a file name (similar to s3) that should match the SHA256 hash of the file content. This will ensure that the uploaded file is unique and can be easily identified per pub key on the hosting provider.
The hosting service will return a hex-prefixed signed URL in the format <domain-name>/<hex-pub-key>/<sha256(file content)?auth=headers. The signed URL will allow the client to upload the file securely to the hosting service that can also check if the pubkey uploading the file is a paid user to allow uploads. On CDN such as AWS s3, the file name would be <hex-pub-key>/<sha256(file content)>. In some cases <domain-name> used to upload is different from CDN domain the content being served, so we need to conclude a standard way here.
After uploading the file, the client can publish a note that includes the <domain-name> and <sha256(file content)> as separate tags. It is preferable to use a special kind of note for this purpose.
Relays should be able to publish all such notes and STORE them.
The <domain-name> should be modifiable by the file uploader in case of censorship or expiry or change of hosting provider. Clients should be able to know when the <domain-name> for all notes uploaded and signed by a given public key is no longer active and be able to render the content using a different <domain-name>. This can be achieved by making the note a replaceable event.
Hosting provider can provide option to download my content that can be easily moved to another hosting provider as the file path convention is kept standard.

thoughts?

ghost commented 1 year ago

perhaps another kind should be picked for this, instead of rewriting relay software. Me and Cole (author of git-nostr) are currently using 7777 as event but i think this should be a standard for blobs or large files.

And for lookups, perhaps we can add some tags such as hash-digest, filename, filesize etc

Still a rough idea, but i think it'll be very good to have a kind that is not only for images or files, but can also be used to publish other binary data

I'll write some examples tomorrow morning

arthurfranca commented 1 year ago

~NIP-23 sets a precedent when adding image tag. It could also be used with references as #[tag index] inside content for inline image.~

Meanwhile I also expect most relays to block large events as time goes by unless they're being well-paid for that, so the data-url hack will eventually stop working.

It is possible to compress image up to desired size, then turn it into a data url as @earonesty wants, so staying within relay event size limits.

Why URLs won't work?

~Some images with content-type application/octet-stream on aws s3 for example have no extension (no .jpg, .gif, ...)~

vitorpamplona commented 1 year ago

The following could work:

New event kind where content is the Data URL alone: data:image/png;base64,...
The Text Note Event that wants to use/display that Image in the middle of the text simply cites it in a tag: [0] -> ["e", "hexcode", "relay.."].
Clients that see the tag in the content can request the image by event ID and display it in the best way they can.

It would be very similar to what we do with Quoted Posts right now.

Clients could then offer direct Image Upload into relays.

Images (and other files) could then be directly liked, zapped, reported, searched, etc.

And the idea of an external nostr:note1 -> image could also work.

We could have relays that only serve this type of larger event (probably through heavy caching mechanisms).

Then a real decentralized TikTok competitor could really emerge.

The only issue is that representing binary content as base64 inside a JSON file is quite a waste of space.

nostr-protocol / nips

"attached" url field #100