Patchwork: Publish and Preview button hangs at Publishing when url exists in message

Created on 18 Feb 2020  路  13Comments  路  Source: ssbc/patchwork

I am running the latest release 3.17.3.729.

I am unable to publish a message that contains a url of any kind. I have tried formatting specifically with markdown format and just using a raw URL but nothing seems to work.

Screenshot 2020-02-17 21 13 27
Screenshot 2020-02-17 21 13 46

good first issue bug

All 13 comments

Just forgot I could open a console to see what was happening. I am getting this in the console as an error.

TypeError: Cannot read property 'link' of null
    at /Applications/Patchwork.app/Contents/Resources/app.asar/lib/depject/message/html/compose.js:272
    at Array.map (<anonymous>)
    at HTMLButtonElement.publish (/Applications/Patchwork.app/Contents/Resources/app.asar/lib/depject/message/html/compose.js:270)

Same here...

I've downgraded to v3.17.2 and then it is ok.

Have had the same issue with any URL pasted in. I tested AppImages v3.17.2-2 and v3.17.3 and only older version works 100%. I've had to revert to using older version too.

On Manjaro KDE latest stable release.

Perhaps I should have mentioned that I am on Mac OS X 10.15.3 (19D76).

Thanks for reporting this! I've seen this bug before, here was the fix in Oasis: https://github.com/fraction/oasis/commit/37c356ccb898fb2bbc73de9e8013bb6694e97f0a

I think we'll just need to apply the same fix. Sorry for the headache.

Fixed in 3.17.4! Thanks again for reporting this, hope this fix works for you.

Unfortunately not fully for me. Yes the Preview now does come up fine (no longer freezes there) and the preview correctly shows the plain URL but it is not showing the markdown for an image again. I took the identical markdown and pasted it into v3.17.2 and it shows 100%. See attached. Top one is 3.172 and bottom 3.17.4.

[
Patchwork 3 17 2

Patchwork 3 17 4

](url)

I think that was a bug -- the SSB-Markdown was meant to render only blob images, not remote HTTP interfaces, so that they'd all continue to work offline, but there was a regression where we were allowing remote HTTP images (https://github.com/ssbc/ssb-markdown/issues/51).

That's resolved now in the latest version, but I understand it's probably very frustrating that the images you published aren't working anymore. I'm real sorry about that, I think the bug was my fault. :/

OK but uploading blob images, is that not going to expand everyone's storage if it gets replicated? I thought it was a better thing to link to images and keep the replication lighter. I think there is a size limit too, which means we'd have to first open every image and reduce from 10MB to below 5MB or so, or will it resize automatically? To be honest I liked the remote HTTP images.

Right, I totally understand that it's inconvenient, but it's the convention that we've been using and I don't have the ability to overturn that protocol without deep community consensus. If only one client supports remote HTTP images then they'll be broken in other clients, which I don't think is something that we want.

It would great to be able to import a blob from a URL, auto-resizing until it's <= 5 MB, but changing the protocol is a larger change that I can't make unilaterally. I think it might be useful to discuss changing the maximum blob size, or adding some feature where big blobs are removed as soon as they're done being used (like how HTTP images are downloaded and maybe cached, but usually thrown away), but I'd be surprised if there was a big movement to support 饾枮饾枈 饾枖饾枒饾枆饾枈 饾枩饾枈饾枃 and support remote HTTP URLs (without the content-addressability we expect from distributed systems like SSB/IPFS/BitTorrent/etc).

OK thanks. Where would the best place be to discuss these options as I realise no-one reaches everyone on Scuttlebutt itself?

To me the client option for users to decide whether to show remote images or not is the lightest and easiest as its already supported by markdown formatting within the text, and does not mean changing the protocol. But yes I get it some clients won't be able to display, and many users may just opt to not display. But it may be interesting to hear if there is support for some easy way to do it.

Ironic thing was I was drawn to Patchwork a month back as Aether only supported image display from two whitelisted sites so I had no idea that part of markdown was supposed to be disabled in the clients. And I promoted it in my YouTube video as a plus funnily enough over Aether ;-) but I'll fix that.

Ah OK I found this reply now at https://github.com/ssbc/ssb-markdown/issues/51 that probably explains why people did not want remote HTTP images:

"This is very undesired behaviour - basically we wanted to prevent this happening in scuttlebutt because it leaks information about the location and reading-habits of users to the www."

Let me see what I can do with blobs ;-)

@Danie10 there's also the relatively deep assumption throughout ssb that if you have a post on your machine you should be able to fully read it offline.
That is, when your ssb-server encounters a blob reference, it will try to retrieve it while you're online. That way, anything you want to read (e.g. blog type messages are stored as blobs) can be rendered offline.
The storage is not really an issue. I've been very aggressively storing everything my ssb-server can get its hands on (high number of hops) and my ssb folder is 13GB. That may sound like a lot, but contemporary laptops have plenty space. Plus, blobs are typically limited to 5MB each. So the impact is somewhat limited.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mmckegg picture mmckegg  路  5Comments

slinlee picture slinlee  路  4Comments

molstrangler picture molstrangler  路  7Comments

cblgh picture cblgh  路  8Comments

entron picture entron  路  6Comments