@mojo Just keep telling people you don't know what IPFS is without coming outright and saying it. Lol.
"IpFs GeTs PaId In FiLe CoIn"
IPFS is a protocol, you nitwit. That's like saying "ActivityPub is gets paid in Filecoin" Makes no fucking sense. Build a Fediverse layer on IPFS, no crypto needed. FFS get educated before you start trying to talk to adults.
The long term solution is something like IPFS object storage that's read only for everyone but the author instance. One copy of the data but all instances can read it and it's stored forever in a redundant medium with bitrot protection.
@ernest It stopped federating again. I restarted my instance, but still nothing I post on my node is coming to kbin.social. If i post to kbin.social, it federates to my node without a problem.
@ernest I restarted my instance and it seems to be receiving federated content from kbin.social, but any content I post isn't being received by kbin.social.
I just tried this, but it doesn't seem like it's really ready for anything but a basic test environment.
When your system creates the service, it does so with the default elestio domain and there is no way to change it from within KBin, therefore your are stuck with a huge security hole and a nonsense domain name that's impossible for people to remember.
While you can indeed use your own domain name to resolve it, it doesn't appear that the domain is editable once KBin is setup (which is done automatically, and understandably on the federation side, you can't have the domain name changing)... so when you set up a KBin on Elestio, you are forever suck with "kbin-????-u5400.vm.elestio.app" as your server name in the Fediverse, which sucks and is really a non-starter.
I don't want to be @HamSwagwich@kbin-mynewkbininstance-u5400.vm.elestio.app
This appears to have the added effect of making it impossible to use Cloudflare as your proxy, since you get a bunch of 301 redirects bouncing between your resolved domain and the elestio domain, since KBin thinks it's name is the elastio domain and rediredts you, then our browser thinks it's going to the resolved domain and redirects you. Boing boing boing
That's correct and that's the problem. If a given community server goes down, that community basically just becomes an archive. It really needs to be able to continue without the host instance, similar to how a mesh works. Each remaining server routes around the dead node.
There is also the problem of search engine indexing... If a given server goes down, that information is lost to the search engine, even though it's still on other nodes.
Which also leads to duplicate content problem for search engines, as ECU m each node of a given community contains the same information for a given post, making it crappy to index and search.
@mojo Just keep telling people you don't know what IPFS is without coming outright and saying it. Lol.
"IpFs GeTs PaId In FiLe CoIn"
IPFS is a protocol, you nitwit. That's like saying "ActivityPub is gets paid in Filecoin" Makes no fucking sense. Build a Fediverse layer on IPFS, no crypto needed. FFS get educated before you start trying to talk to adults.
Jesus... just stop.
@Kalcifer
@mojo Tell me you don't know what IPFS without telling me you don't know what IPFS is, lol. What the fuck does IPFS have to do with crypto?
@Kalcifer
@kavides
Oops thank you
@Kalcifer
The long term solution is something like IPFS object storage that's read only for everyone but the author instance. One copy of the data but all instances can read it and it's stored forever in a redundant medium with bitrot protection.
@Sam_uk
I've been running one. showeq.com
The basic service gets overloaded quickly and you'll need to upgrade if you get any traction at all.
Also, since KBin federation is broken, it's not great
@1Fuji2Taka3Nasubi
Yes it does. My KBin node is not federating with KBin.social or only works intermittently.
@ernest It stopped federating again. I restarted my instance, but still nothing I post on my node is coming to kbin.social. If i post to kbin.social, it federates to my node without a problem.
@ernest it started working a couple hours ago. No idea why . Thought maybe you knocked something loose
@revampeduser I would really like to see this as well. Now if I can just figure out how to host my own Peertube instance... /sigh
@ernest I restarted my instance and it seems to be receiving federated content from kbin.social, but any content I post isn't being received by kbin.social.
It's showeq.com
I appreciate you checking into it
So... Scientology, but with more Zuck
Thank you for the reply! I'm still not getting any federated content either direction with my node from KBin.social
I'm running a KBin node for the record, not Lemmy
Still working on it?
What do you mean "quickly?"
@jbenguira
I just tried this, but it doesn't seem like it's really ready for anything but a basic test environment.
When your system creates the service, it does so with the default elestio domain and there is no way to change it from within KBin, therefore your are stuck with a huge security hole and a nonsense domain name that's impossible for people to remember.
While you can indeed use your own domain name to resolve it, it doesn't appear that the domain is editable once KBin is setup (which is done automatically, and understandably on the federation side, you can't have the domain name changing)... so when you set up a KBin on Elestio, you are forever suck with "kbin-????-u5400.vm.elestio.app" as your server name in the Fediverse, which sucks and is really a non-starter.
I don't want to be
@HamSwagwich@kbin-mynewkbininstance-u5400.vm.elestio.appThis appears to have the added effect of making it impossible to use Cloudflare as your proxy, since you get a bunch of 301 redirects bouncing between your resolved domain and the elestio domain, since KBin thinks it's name is the elastio domain and rediredts you, then our browser thinks it's going to the resolved domain and redirects you. Boing boing boing
That's correct and that's the problem. If a given community server goes down, that community basically just becomes an archive. It really needs to be able to continue without the host instance, similar to how a mesh works. Each remaining server routes around the dead node.
There is also the problem of search engine indexing... If a given server goes down, that information is lost to the search engine, even though it's still on other nodes.
Which also leads to duplicate content problem for search engines, as ECU m each node of a given community contains the same information for a given post, making it crappy to index and search.
400C is like 650K. Not even close to absolute zero
Indeed, and when you kiss someone you are making one big hole connected by two assholes.
The Rhetoric is starting to sound a like like the DPRK
The RCS issue hits the nail on the head I think. It's really the biggest stumbling block for everyone at this point.