The existing avatar fallback relies on a blob I don't have.
%ZCz/WJXHvBB/2QkGiPAO8fJ+nL0G26IfHvoIdGl4TLg=.sha256
master
from mixmix / patchbay-mix / reliable_avatar_fallback
The existing avatar fallback relies on a blob I don't have. It makes patchbay ugly. This pull request alleviates that somewhat
It is probably a good idea to not depend on specific blob ids in the client, unless the client provides them, since users with new installations will not have any blobs. The themes picker should maybe do something similar too for the default theme.
@cel Should we check the default theme and a fallback image into the master branch of Patchbay?
@ev for the theme it might be a good idea, to improve onboarding experience. for the fallback image, that is what this PR does.
yep, I don't have that blob, so py patchbay looks super patchy. We could make a module which is the 'accessible defaults'... but in the meantime would be good to merge this
thanks, merged into 3.0.1
Oh, I just realized that this breaks the liteclient, which can't see the local disk (and was the reason for using blobs, here)
Really, we just should make blobs be fast.
@dominic what happened to the IPFS--sbot conversation re: blog fastness?
@dominic *blob -- that was re: our conversation on Wednesday with @cryptix @ev @cel and myself, so I guess you aren't in on that loop. Or, are you?
The bootloader is working for me now!!!!!!
@gb Well, we haven't done anything with IPFS yet. We were just talking about how maybe it was a blobstore option that seems to work and is being developed by another team. So abstracting away to it might help offload the burdon of maintaining that part of the application structure. <-- gist of the conversation.
That was on the call that I missed. If I had been there, I would have pointed out two things:
the ipfs model works best if the blobs are popular - you have to connect to peers which also want them, not really the long tail though,
And it also doesn't provide much privacy. You have to advertise which blobs you have on a DHT, accessible to everyone, so you'll never have very good privacy about which blobs you have.
Where as, by gossiping the blobs, you'll get some extras, and you can plausably claim "I was just holding this for a friend"
Though, having blobs that just worked quickly is the most important immediate thing...
The big concern we talked about on the call revolved around the growing size of the blobstore, just under 2 gigs. I don't mind hosting @cryptix's live shows, but what happens if we have someone jumps on the network who starts uploading more than that?
For example: when someone wanted to shut down Bitmessage, they just sent 20 megabyte attachments every five minutes or something, and everyone had to host them, blowing out everyone's Internet. They were secure attachments! But that was the downfall of that service, as far as I remember it.
The trouble with bitmessage is that it uniformly distributes work, which is good for privacy but unfortunately good faith is not uniformly distributed.
I think we should try a few things and see if we can get blobs working well. The first thing, should be merging my ssb-blobs PR. https://github.com/ssbc/scuttlebot/pull/348
Built with git-ssb-web