http://p6nhckzlonbw72mhxqcyfa474ssavlnud6tvpmhjzf37r2zyz2ommtqd.onion/files/rfc-hlfchand.ps I was gonna post an ascii version of the document, but apparently one and a half page is too large for a post here, so have a .ps instead. In short: I want to create a headless fchannel server, that is, a server compatible with the fchannel protocol, capable of talking to other instances, but that does not offer a web interface. To interact with it either use another instance or use a client (like FBI). But I want to hear what other people (in particular devchad) think before I start working on it.
>>fprog-KP506HJA (OP) that would definitely be pretty cool. Keep in mind the size of the fchan userbase before doing this of course. Your software so far has been pretty cool, but we have a pretty small amount of people that frequent this site, let alone want to set up a private instance w/ FBI. If you don't mind a very small amount of people doing this, i'd say go for it. I'd definitely give it a try.
>>fprog-QG14KWXP I know. I would be lying if I said it isn't a bummer that nobody has tried to contribute to my projects. Or even criticize my code, I still have no idea if it is legible for others. But it is fun to work on these projects, I get quite bored when I am not doing anything. After I was done with FBI, I got a yearning to do something more, then I got the idea that since there is now a client to create an interface, servers wouldn't have to provide their own anymore. Plus it is nice to help set the groundwork for the future of FChannel. I hope in future we will have a greater variety of client and server software to choose from.
>>fprog-KP506HJA (OP) originally FChannel had a separate server and client but i choose to merge them into one to make it more accessible. it would not be hard to convert FChannel to just be a headless server, you would just have to exclude the client.go and remove some routing in main.go like OutboxGet(), PostGet(), CatalogGet() one thing to consider with other clients connecting to a server to use would be authentication. something that would need to be implemented for this would need to be issuing API keys to clients which would allow posting to the server. the servers have a private key they sign all posts with and I am sure server admins would not want to share that so an API key might be issued to clients to use for posting. any development to push federated imageboards is worth exploring imo. ive been on vacation so havent been able to check out FBI other than what has been updated in the posts.
>>fprog-KP506HJA (OP) can't you just do this by not pointing nginx to an html page? just delete the fchannel html or whatever
>>fprog-G8N5LSWO yeah, i get that, i know i've said this a million times by this point, but one of these days i will get around to hosting a git server and contributing... i'm just a lazy motherfucker
>>fprog-UXDPYKRS Thank you for the directions, I will read the source this weekend. I might as well write my findings, try to create a document specifying FChannel's protocol. >>fprog-WB82C24R That'd be a sub-optimal solution, if I simply blocked access to html pages to code would still exist. I prefer to write simpler software that runs low on resources, so it's either forking and overhauling FChannel-Server (I don't know Go) or writing something from scratch (maybe taking some ideas from the original). >>fprog-YEE3WQ9Y Let me help you, fedifren. Where do you plan to host it? Your usual computer, dedicated computer, virtual machine, or rented server? I recommend a dedicated computer for security or, if you don't have one, a virtual machine. Once you got that covered, I can help you get a setup similar to mine in one afternoon (took me longer than that to do it, but I was still figuring things out, you probably saw the thread on /b/). It doesn't have to be perfect from the start, it took me some trial and error to setup the server in a way I like.
>>fprog-HAUI4N9G i have a Raspberry Pi Zero that I think i'll use. it's going to be an onion service, but the thing also is my router is fucking weird and port forwarding can be a bitch (because it's all locked behind an ISP specific phone app), which is another reason i'm too lazy to do it.
>>fprog-EARC8598 Since it is gonna be an onion service, you don't have to bother with port forwarding or talking to your ISP, Tor punches through NAT like a bullying taking money from a nerd. See >>fmeta-TH5BX0W7 → to know how much trouble hosting an onion service saves you. If you already have the hardware and an operating system running on it, you just have to install nginx and tor and you can have your own darkwebsite in no time.
>>fprog-O53JGV6B that was actually my thread, i was unaware port forwarding wasn't necessary. Good to know! I'll probably set it up tomorrow.
>>fprog-HAUI4N9G I took some time to read main(), I kinda understand the initialization, but I skimmed through all the http.HandleFunc() calls. The server appears to be request-oriented, only doing work as a response to requests, so the handle functions contain the meat of the code and I will need to look into them with more care. I should probably try to run the server myself to get a better grip of how it all works. >>fprog-S6673O9N Well? No need to shy when shilling your website here, everybody is doing it.
Almost forgot to report my /prog/ress. http://git.p6nhckzlonbw72mhxqcyfa474ssavlnud6tvpmhjzf37r2zyz2ommtqd.onion/fchand/file/README.html There is what I have come up with so far, I have only started to create an HTTP simulacrum to process the GET and POST requests. I won't bother with a real HTTP since it won't serve HTML documents, the HTTP is there just to be compatible with the current protocol (maybe later we can work on something dependent only on TCP/IP). I will now study about POST requests so I can know how the data will show up and then work on storing it in a database.
I had tossed the project aside for long while, but yesterday I got back to it and tried to get POST requests working, took a while, but I did it. However it made it realize that trying to create an HTTP server from scratch is a real bitch, so I have decided to try that again using CGI instead, since using a real HTTP server will save a lot of trouble like encryption and compression (on top of basic features like POST request, which was hard enough). I may try the BLES stack mentioned on >>fg-I31BT8YD →, I understand nginx and Lua pretty well, so I will just need to study CGI and how to host a server on BSD.
>>fprog-O53JGV6B You are a nerd, anon. We are all nerds here. Like a bully taking money from us?
Here is my Christmas gift for you: a half-working alternative implementation of FChannel on Lua. [1] From my tests, it is well enough-ish for a lonesome IB. It works alright on my custom HTTPd (TBH) [2] and FBI [3] is now capable to rendering its outbox (needed some tweaks). I will probably need devchad's help to implement federation properly. [1] http://git.p6nhckzlonbw72mhxqcyfa474ssavlnud6tvpmhjzf37r2zyz2ommtqd.onion/csam/file/README.html [2] http://git.p6nhckzlonbw72mhxqcyfa474ssavlnud6tvpmhjzf37r2zyz2ommtqd.onion/tbh/file/README.html [3] http://git.p6nhckzlonbw72mhxqcyfa474ssavlnud6tvpmhjzf37r2zyz2ommtqd.onion/fbi/file/README.html ok so basically i now have a full suite of autismoware that might be passable as an imageboard with some more work
>>fprog-NQBS1WAK based as fuck
>>fprog-NQBS1WAK hellyeah
>>fprog-G9LN4CVK >>fprog-OVRSFZHD samefag
I have been thinking of adapting FBI (the fchannel client I wrote) to be a local webserver that you access with your browser (currently it just spits HTML files for you to browse on the file system). I think this would be easier to use, and would make it simpler for me to implement more functionalities. Not having to worry about the clutter files generated is nice too. FBI is currently very slow to generate the files (takes ~1s, time to download attachments notwithstanding), but I am fairly certain that's because it has to open and process the contents of the outboxes every time it is run. If I adapted that shitty webserver I wrote to use a Lua state, all that work would need to be done on startup and when the outboxes are updated. Plus I could build tables in a way that, although more taxing initially, would make it easier to generate the pages later on. And the attachments could be downloaded parallelly and asynchronously, so no more waiting for everything to download serially. I didn't give security much thought when I wrote that webserver because I intended it to be used only locally, so for the most part it shouldn't be a concern when using FBI. The only cases when the server would connect outside of localhost would be: when downloading outboxes (probably done with curl anyway, so it's fine), and when making a POST request to an instance (only dangerous if the instance is malicious, so I will need to be careful here). Thoughts?
>>fprog-JHLFXYTG I don’t really follow the value proposition. If your client is a local web server, then what do you gain by not viewing the remote server with your browser? More control over JS and appearance? My next question is why not try an electron app if you’re going that far?
>>fprog-8UGQ6KQU >what do you gain by not viewing the remote server with your browser? You can directly control which instances you "subscribe" to instead of relying on an admin doing proper federation or having to open 10 tabs to check all of them. You also get to keep a local archive of posts. Plus, the existence of a standalone client allows people to use headless servers, and I plan to make it easy to create custom appearances for the client so they can use that instead of writing a frontend from scratch. >More control over JS and appearance? This too. I also intend to implement the coveted overboard. >My next question is why not try an electron app if you’re going that far? >why not try an electron app >electron app >electron >app >APP
>>fprog-VK8O6OE5 OK, well that makes a lot more sense. That doesn’t seem like a bad idea. You can hate on electron, but it’s basically just a slightly smaller browser, which is going to be pretty comparable to using your browser. Also i’m sorry, but Steve Jobs won. Everything is an application now, or app for short. You seem like a pretty motivated guy, are you the maintainer of F Chan? You don’t have to answer that, but it would be nice if us shitty phone posters got a little bit of love. The site is pretty hard to read on a mobile device.
>>fprog-8UGQ6KQU >why not try an electron app BLOAT please do not encourage shit frameworks that make the world a worse place
>>fprog-BZRKPMZ5 >You can hate on electron, but it’s basically just a slightly smaller browser >just a slightly smaller browser >uses chromium Still a hard pass. >Also i’m sorry, but Steve Jobs won. Everything is an application now, or app for short. Maybe on your glowphone. On a real computer programs are still called programs. >You seem like a pretty motivated guy >motivated lol I work on these projects on and off, like a couple of weeks doing actual work followed by a couple of months doing fuckall. >are you the maintainer of F Chan? I'm not a chad nor a saint, sorry. >but it would be nice if us shitty phone posters got a little bit of love. The site is pretty hard to read on a mobile device. As it should be. Pic related.
>>fprog-M0JUF1P3 Electron is too bloated. So its better to use a full browser. Do I have that right? >>fprog-R05TO6VC That’s a pretty ridiculous rationalization for not knowing CSS. Actual mulattos know media queries. I’m also not following why Chromium is a problem. Every other engine is actually worse. Gecko is terrible. WebKit is also worse, but at least not maintained by unhinged Mozilla trannies.
>>fprog-PQRNLCPI >That’s a pretty ridiculous rationalization for not knowing CSS. Who mentioned CSS, schizo?
>>fprog-PQRNLCPI A full browser shouldn't require to emulate nuclear fission just to load a faggoty animation, nor ask you to covalently sell your soul to some niggerfaggot for a piece of information you could deduct with a little more thought.
All trademarks and copyrights on this page are owned by their respective parties.
v0.2.0-c793a28