You are reading content from Scuttlebutt
@mix %VU1C/HpB04Sr9+D3M6JABTCddQSz3Abm2QBBd4MTmZw=.sha256
Re: %9/2M5lUET

Choice @cel , can we also do something like :

curl -s 'http://scuttlebot.io/blobs/get/&e6TJkl1uR+oJFMq0irowdoB49ZcPYbXVDsFoO/UJZzU=.sha256' | sh

It would sidestep the "I don't have that blob" bootstrapping problem

@Christian Bundy %RfNISGuvRYVgAP0ujMKVAma/OM3U/QWIrEiNiJ0QtxU=.sha256

@mix

Might be worth URL-encoding it too. 😬

On my server that forward-slash makes the route get parsed as:

/blobs/get/:a/:b
@mix %iyzqSg4MzTv8IHHzRABIl6ImAJL8Wc2tJQi0f7phAYc=.sha256

I dunno I was just kicking the tyre ... no idea what the blob provider on scuttlebot.io is ... perhaps I should be hitting viewer.scuttlebot.io?

@mix %ZY1BUSkLA6ps6WX7ct6VmKE4951WhVe/ilkAsdkOjbk=.sha256

cc @christianbundy🌟

@cel %Bt/X5dbcP0XIJZkMteI7P7H0vw5X+9YMm9OnetOSoTI=.sha256
Content warning: thought process

@mixmix %VU1C/Hp... %iyzqSg4...

Currently, viewer.scuttlebot.io (ssb-viewer) and git.scuttlebot.io (git-ssb-web) serve blob requests (with or without URL-encoding). There could be added another subdomain just for blobs. (side question: for missing blobs, should it want them or return 404?)

For the installer, I wonder then how the installer script picks which host to fetch subsequent blobs from. &e6TJkl1... is hard-coded to use localhost:8989. &ErUlQYe... lets it be overridden with a env var $BLOBS_PREFIX (but it doesn't verify the hash of the received data).
So you can use the existing script like this (trusting the remote server to send the correct blobs):

export BLOBS_PREFIX='https://viewer.scuttlebot.io'
curl -s "$BLOBS_PREFIX/&ErUlQYegJprhEZUNO/HwHQ2UES+XUpT1XIb27GTGjT0=.sha256" | sh

I experimented with trying to make the script be able to detect the URL it is being fetched from, using pgrep -fa curl, but that did not work: curl already exited by the time the script is running. I don't suppose there is a way to recover the exited process's name from the file descriptor. So it seems the thing to do is hard code a server URL(s). Maybe take some input from the environment, or something in ~/.ssb… or maybe not.

It looks to me then that this has to be a separate installer script from the localhost one. Because if fetching via localhost:8989 is viable, I think that should be used. But I don't see a way for the script to make that decision.

@mix %09BaBG+JxoVGr9oBdFDxa1uB6I3+T0U9F+ICa5I35AA=.sha256

The main use case IMO is one where all the blobs needed are served by a remote server.
I could be wrong, but the case I'm worried about is a person keen to try git-ssb, but new to the scuttlebutts tries this "easy" install curl path, but then they don't have the blobs, so ... the script kicks off the wants, but then just waits for blobs which either never arrive or take ages to arrive?

At which point the person gives up and assumes it's all broken.

I mighta misunderstood how things work, but is this a story which helps you make any decisions @cel ?

@cel %F/bLYxYVIbig1SIBgeM0TItgDkqumayHXsnIkDzODlE=.sha256

@mixmix, yes, that helps.

Installing from blobs should work if you do it from finding a message on SSB announcing them. It should work just as well as images loading in posts. (If it doesn't, I would like to work on that.) But if you find the blob/script from outside SSB, it is less likely to work. So I need to work on that use case.

@mix %gbG0kDvaCyXByq9UlDMWXA/PkTIOaP3pefxekiy6aQA=.sha256
Voted @mixmix, yes, that helps. Installing from blobs should work if you do it f
Join Scuttlebutt now