Opt-in for publicWebHosting: %7LOOkzL...
deployed on viewer.scuttlebot.io.

Hi @cel ,
is there an sbot command we can type to send appropriate message to change the privacy setting?

@LanceW

id="$(sbot whoami | grep -o '@.*ed25519')"

To allow public web hosting of your feed:

sbot publish --type about --about "$id" --publicWebHosting

To disallow it:

sbot publish --type about --about "$id" --no-publicWebHosting

Cool, thanks!

Hi @cel,
I have now I think set myself to public web hosting, but viewer.scuttlebot.io seems to be hiding some of my posts.

For me: https://viewer.scuttlebot.io/%25Rm7Bo44sEMELc8HTvgNPK4UR7KWXZwJyHpEw7%2FERTH8%3D.sha256 is visible
But http://viewer.scuttlebot.io/%25l%2FpyaliIVTGinmPdA%2B581zJeQfAGezGJRCRHn56ZcU0%3D.sha256 is not

Thoughts? What could I try

Super weird, it's definitely local to me, possible http vs https. Thanks for the reply @alanz

@LanceW this server is behind a nginx reverse-proxy, caching responses for up to 1 day

@cel Do you (or anyone) know if there is any way to opt in from #patchwork or #patchbay? (or I guess I'm gonna check in patchbay in a minute, just gotta switch clients )

I think I managed to opt in now, %fAH/6NF.... Found the sbot used by patchbay and used that hehe

opt'ed in with

sbot publish --type about --about "$(sbot whoami | jq -r .id | xargs echo -n)" --publicWebHosting

^ %K0KvhJK...

re: %Lsocm+5... %jthKri6...

In Patchbay, you used to be able to publish arbitrary messages - if you wrote a valid JSON object as a message text, it would be used as-is instead of being turned into a post-type message. So you could publish an opt-in message {"type":"about","about":"YOUR_ID","publicWebHosting":true}, filling in your key id (@…ed25519) for YOUR_ID. I don't know if Patchbay still allows this though. You could also use sbotc to publish the message, which may or may not be easier to install than sbot: sbotc publish '{"type":"about"…}'.

The night after I deployed this change, I dreamed I met with a woman who worked at Twitter (?), and she was telling me how she had been instructed to follow some feeds (?) and there was a problem with them that she was having trouble with. She said "we lost a lot of ranking". She gestured to emphasize the difference in level of access to view and to edit (?); I responded by saying, well, email is the same way, you cannot change an email after it is sent. Then I was shown their "proprietary gateway" which was a Macintosh Plus running off a floppy disk, with the monitor removed / papered-over and a phone-line connection on the front. #dreams

I apologize to everyone who has shared, or is attempting to follow, links to viewer.scuttlebot.io that are now effectively broken.

@cel I would expect that feature was lost in the rewrite that become patchbay 7.

In latest patchbay you can now change this on your /profile

@noffle in latest ssb-viewer, opt-in/out is in fact ternary, where the behavior of the default null (instead of true or false) is configurable by the instance, currently defaulting to be the same as false (opt-in). Old ssb-viewers will still treat the null as false.

Making the default be to use a cutoff date would help make available old/historic data. But my understanding is that some people were upset that content of theirs was available during that time at all. And also the viewer might find new feeds which have messages from before the date which would then suddenly be available. i.e. limitations of timestamps in a distributed system. So I am not sure it would be appropriate here.

@juul latest ssb-viewer has this robots.txt:

User-agent: *
Disallow: /

So the effect of opt-in now should be as you say, for up-to-date ssb-viewers. We could add back robots-indexing on a per-feed or per-message basis with meta tags.

@juul @cel

I've been thinking about the robots.txt solution for a few days, and I think that limited web interactions is a good idea, but I wonder whether something like send.firefox.com would work for us.

Instead of the current "copy external link" mechanism in the clients I've used, it seems to me that we could instead have a viewer that shows its private messages to the world. For example, let's say Alice is a user, Bob is a viewer, and Carol is the recipient.

1. Alice wants to share a cat photo with Carol.
2. Alice sends a private message to Bob with the cat photo.
3. Bob replies with a link to the private message on the web viewer.
4. Alice sends the link to Carol.
5. Carol opens the link in a web browser.
6. Bob retrieves the content and sends it to Carol.
7. After 5 downloads or 24 hours, Bob deletes the blob(s).

This means that Carol's view of the network is dependent on what Alice can see, not what Bob can see, and also means that randos can't search/scrape the network from the web. I'm not sure whether this is a good idea, but something with a similar shape has been banging around in my head for a few days. Regardless, it seems like there are only a few important things:

1. Alice should be able to share content with Carol.
2. Bob should be able to act as an intermediary.
3. Randos shouldn't be able to scrape the whole network from the web.