Pocket Gopher

So I was reading the first issue of lainzine and came across the gopher protocol. It sounded pretty simple and I eventually learned that its current community intercepted with the BBS and usenet community pretty heavily. I needed a project to do and so spent the next few weeks learning java as I developed a gopher client for android. It's at a point where you can browse probably over 95% of gopher servers without noticing lack of support for certain features (many server implement non-standard stuff, so I need people to use the app and request features). Here's the git for it: https://github.com/afonsotrepa/PocketGopher I plan on releasing it on F-droid in the coming days, just missing a decent icon. I'll upload the compiled apk to github or something for those that don't want to compile the code themselves. Feel free to contact me on the lainchan irc (nick: gxt) or my email (check github profile).

posting screenshots just to prove it isn’t complete soykaf

>>4914 And here's the apk. (still a debug apk, not a full release) https://github.com/afonsotrepa/PocketGopher/releases/tag/0.1.0

>>4914 Better, don't release nothing. You must improve this app before publish. Non-Model View Presenter pattern. Non-Android Annotations Slash Dagger. Use MVP + AA + Retrofit. Build first your app base, after that start doing real things.

>>4919 I agree. While it's a good idea, there is no such a thing as a peer review to search for possible bugs and exploits. BUT, he needs to release it for users to find flaws in it. Such a conundrum.

>>4919 >Retrofit turns your HTTP API into a Java interface. B-but gopher doesn't use HTTP at all???

>>4922 HTTP != Goph i knw, just i made a mistake. Remove Retrofit and still he needs to do some things first.

>>4923 And don't forget EventBus.

>>4921 >>4924 >tfw my weeks-long project is getting soykafposted into oblivion >>4923 > he needs to do some things first. Yeah that's why I'm releasing the project. Looking for feature requests.

>>4925 Be proud btw. Maybe I'll check later. (2 hours) [[working]]

>>4926 Alrighty, thanks. I'll see if I can get someone more experienced with gopher to help me wage slave the project in the right places.

>>4927 I'm working with Android, I should change to Kotlin but I'll wait a bit, I need to improve my mind inside Android projects. Another way it's using hybrid system like Ionic, my boss told me again about that. Still trying to refuse but I love Javascript with Prototypes. I'm not talking about ES5.

>>4928 I am angry you can stop it with the Indian memes now thanks

>>4929 (?) Inidian memes? Why I should troll about this thread? This isn't 4chan dude.

>>4930 Oh, sorry for sperging out at you, thought you were joking. >I love Javascript kinda hard to believe a man that would say such a thing ykno?

>>4932 I know this meme bro. I know how people see JS. What about If I tell you I use ASM x86-64? Would you say something like go and use fortran?. Just stop trying to slide, I'm here for talk with OP.

Here's the static website/github page btw: https://afonsotrepa.github.io/PocketGopher/ >>4933 huh, I am the OP. I genuinely thought you were brewing soykaf due to the previous soykafposts in the thread, sorry. While working on the app I was quite tempted to use some frameworks and libraries but I decided against it to: 1. keep the code simple and easy for people to contribute to 2.avoid using non-standard behavior 3.keep it light (gopher itself is alright a pretty light protocol, so I didn't want to go against that philosophy) Thanks for the interest btw, I do really appreciate it. What exactly do you like about JS btw? I've been thinking about dipping my toe in it due to some of its lisp-like qualities but I tend to avoid any web stuff.

>>4919 >frameworks Does android dev really need all these frameworks, or is this like webdevs who don't realise that vanilla html+css can do what they're trying to achieve far more efficiently and compliantly? >>4934 >>4928 Off topic, but if you like prototype inheritance, maybe you should check out Lua, it has far less idiosyncracies IMO.

>>4936 Yeah pretty sure those first few posts were well crafted soykafposts. I'm starting to really not give a damn about language I use. I've spent way too much time using esoteric languages for no real good reason, just meme. I thought I was going to hate java, but I really don't mind it. Its structure can be quite useful for larger programs. The same happened to me when I started to learn C. Thought I'd hate it, ended up loving it.

This looks really sweet. If only there were more gopher servers. The only thing I don't like about java is how horrendously verbose it can be and how few dynamic features it has considering it runs on a VM.

>>4936 >Does android dev really need all these frameworks, or is this like webdevs who don't realise that vanilla html+css can do what they're trying to achieve far more efficiently and compliantly? The second one, by far. I'm very surprised to see so many people agreeing with him in this thread. I've never even needed to directly extend a view before, let alone use the android annotations or a "MVP pattern"

>how few dynamic features it has considering it runs on a VM. What kind of dynamic features do you miss? You can create classes using reflection and load new code from JARs during runtime. That's pretty dynamic in my book.

>>4936 Indu meme here ;) - I'll check LUA, right know i don't have enough time. You need this libraries because you should not waste your time making the notification system,. schedule for threads. AA can help you alot, and the MVP pattern helps you to find your files better,

Release 1.0.0 is live!! Get it here: https://github.com/afonsotrepa/PocketGopher/releases/tag/1.0.0 Spent the day redoing a big part of the backend to support url's. Now the experience should be way more user friendly and consistent. Expect a more robust url system tomorrow.

>>4973 Thanks! I've installed it and will keep using it. It seems to completely ignore "unknown" types now instead of drawing the error (!) symbol as in the alpha releases. The best thing you can probably do with these is treat them as either binaries or text files. It looks like the Bucktooth Gopher server and the Overbite project (both from gopher://gopher.floodgap.com) make use of the following non-standard types: - 's' sound files - 'p' PNG images - 'd' PDF documents - 'c' CSS files - 'x' XML files - 'h' HTML files Presumably these were/are common enough to warrant inclusion by the Floodgap maintainer, but I think even just a download option for any "unknown" type would work just fine.

Neat. Do you have any idea how to set up a gopher page? I've been thinking for a while I'd like to learn one day but didn't find much at a quick glance.

>>4976 I think pygopherd is probably the easiest server to start with, mainly since it's available in the Debian repositories (apt-get install pygopherd). After installing, man pygopherd has all you need to get started. If you just want to play around and know how to use FTP, I set up this a while ago as an experiment that was never used: gopher://khzae.net/1/ftp/sandbox You can create a directory for yourself and put some files/gophermaps in it to learn the basics. If you don't have a Gopher client for your non-mobile device, either OverbiteFF (a plugin for Firefox, not Web Extension compatible yet though) or Lynx are pretty much the best. Or if you want something unique, gopher://gopher.floodgap.com/1/gophervr.

>>4977 And of course if you don't want to host it yourself, an SDF account includes Gopher among its other offerings: http://sdf.org/?tutorials/gopher

>>4975 Are you using version 1.0.0? I thought github had corrupted it, I've removed it and am waiting for their servers to be back in order to upload it again. If you are using 1.0.0 then I've fuarrrked up somewhere cuz that was supposed to be fixed. If you're not sure of wish version you're using just post a screenshot and I'll be able to tell if it's 1.0.0 or not. Oh, thanks for informing me about those other types btw. The client already supports 'd' and 'h' types but the rest I didn't even know about.

>>4980 Oh it was actually a problem on my side, here it is: https://github.com/afonsotrepa/PocketGopher/releases/tag/1.0.0

>>4980 I redownloaded from >>4981 but it seems to be behaving the same way. As an example, there should be another item between 'Search this gopherhole' and 'Hosted with Bucktooth' in the screenshot, a sound clip which Bucktooth defaults to marking as type 's'.

>>4992 Yeah I fixed that today. I'll release it in a few hours after adding a few more features as release 1.1.0. I'll also add audio support to the list of stuff to do (should be pretty easy, might even do it today if I have the time), thanks.

>>4993 textboard based on gopher https://github.com/naomiEve/sakaki/

>>4994 Hm, is that your project fam? I'd test it and contribute if only I knew the language you're using.

>>4995 https://github.com/naomiEve/sakaki/blob/master/src/app.rb Looks like Ruby

>>4996 Yeah that all looks like gibberish to me. Is there any server running it?

>>4998 It's ruby, read a reference, make it and run it, how do you expect to "contribute" if you're not even willing to read/run 150~ LOC?

>>4998 Not the creator but I quickly set up an instance here: gopher://khzae.net:7070

Release 1.1.0 is now live: https://github.com/afonsotrepa/PocketGopher/releases/tag/1.1.0 Just fyi: click on an item's icon to download it (only works for those types that you can't download any other way rn). >>4999 I'm the OP and I don't exactly have time to learn Ruby right now, that's the point I was trying to make. >>5000 ty fam, I'll check it out

>>5001 Excellent. The way 's' and ';' are handled now works great for me. Seems to still crash when trying to download a file when one with the same name already exists in the Downloads folder, but you're probably already working on that.

>>5006 >but you're probably already working on that. No I am not, I thought I had fixed, it sorry. I'll take another look at it in a sec and release a patch. Also, do you like the way images are handled or did you prefer the old way?

>>5007 Seems fine to me, if it keeps things simpler to hand off the image instead of rendering in the app then all the better IMO.

>>5008 Wow, that's rather weird, it really should be working. I'll debug it tomorrow and release a patch, thanks for warning me about it.

>>5006 Alright, I've fixed it and a few others bugs and also added the ability to select text. https://github.com/afonsotrepa/PocketGopher/releases/tag/1.1.1 I'll be working on adding a history. Is there some other feature that you want? Also, I think I'm going to use the web browser to handle html files instead of opening them in webviews, what do you think?

>>5025 Yep, I get the "File already exists" message instead of a crash now. I would kind of prefer it to just overwrite the existing file instead (stuff in my "Downloads" folder is usually temporary anyway), but a better way is probably to prompt the user if they want to overwrite, or do what many web browsers do where additional files with the same name get a (1), (2), (3), ... etc. appended before the file extension. Possible new bug: It seems to always automatically jump to the bottom of menus and text files in 1.1.1. History sounds good. Opening HTML files in the web browser also sounds good. There's some special cases for 'h' items that some servers use too, namely URL: selectors and the older GET selector. gopher://gopher.floodgap.com/0/buck/dbrowse?faquse%205 Basically, an 'h' item with a selector like "URL:http://www.abc.com" is not an HTML file on the Gopher server but a link to an external URL. For example: hPocketGopher<TAB>URL:https://lainchan.org/λ/res/4914.html<TAB>gopherhost.com<TAB>70<CR><LF> Some servers may also make use of an older trick, where the selector is "GET /<path>", the host is the hostname of the HTTP server, and the port is 80. For example: hPocketGopher<TAB>GET /λ/res/4914.html<TAB>lainchan.org<TAB>80<CR><LF> Basically this would make the client treat the HTTP server like a Gopher server on port 80, and sends "GET /<path>" to it, and displays what the HTTP server returns as an HTML file. But nowadays it is better to detect this kind of item and simply open it in the web browser, just like the URL: selector.

I was unaware of gopher's existence, it is what I was looking for, probably going to migrate my site from http to gopher.

>>5028 >>4977 is a good compromise. It acts as both a Gopher server and HTTP server, serving HTML versions of your Gopher menus to people that connect over HTTP. http://gopher.quux.org / gopher://gopher.quux.org is an example.

>>5026 btw, for the newer URL: selectors, I think all servers supporting this will detect when the client tries to interpret it literally (i.e. asks the server for the directory/file named "URL:http://abc.com") and will send back an HTML page with auto-redirect to the real URL, so it does work in the current version of PocketGopher, with the external website being displayed in the app. Pic is what Bucktooth responds with when PocketGopher access this item: hView this Gopherhole over HTTP<TAB>URL:http://khzae.net<TAB>khzae.net<TAB>70<CR><LF>

>>5026 Alright so most of the work today was backend stuff so I'm not going to make another release today, but I do expect to make a release tomorrow that includes all of the things you talked about in your post. That http stuff should be pretty easy, fortunately. Also, do tell me if you notice the app slowing down or blocking up for no good reason cuz I think I need to clean up the way threading is handled. Oh, also, I'l add a way of editing the url of the page you're in (not that useful for gopher, but whatever)

>>5032 >Oh, also, I'l add a way of editing the url of the page you're in (not that useful for gopher, but whatever) I think that can be pretty useful. At least when testing things out, so maybe less useful on a phone client than a PC client, but still a welcome feature. The ease of getting Overbite to view an item differently just by changing the type in the URL has been helpful while browsing older servers that use non-standard types that Overbite doesn't understand, or that conflict with Overbite's non-standard types. I haven't really noticed any big slow downs, but coincidentally I've mainly been using it in places with poor signal quality, so it's hard to tell. But if I notice it when I'm on a decent connection I'll let you know.

Great work, OP! By building our own tools, and by inspiring others to do the same, we can begin to push back against the corporate domination of the web; and therefore in some small way you've helped build a better, more free society. Thank you. You've inspired me to add gopher support to EinChan, available at gopher://einchan.god.jp:70 (currently read only). I hope you inspire many more people to take control, make their own tools or content and share it with the world.

>>5041 B-but I'm working on this project full time to try and get a job ;_; Am I 2corporate4u senpai?

>>5042 Everyone needs cash moneys anon, if you're doing good it doesn't matter why you're doing it. Maybe when you become mr. corporate CEO you can try to make decisions that are good for people.

Okay, here's release 1.2.0: https://github.com/afonsotrepa/PocketGopher/releases/tag/1.2.0 "Added: History Better support for most file types Better support for html files (HTTP) The ability to edit the url of the current page Also fixed a few bugs and made minor changes (check commits)" I think that's all we discussed in the thread, but do tell me if something is missing. Obviously also looking for more recommendations of stuff to be added/fixed.

>>5064 Thanks! The display text of all 'h' items appears is appearing as "null" for me with 1.2.0

>>5069 Yeah I noticed it but thought it was caused by the server. But now that you mention it I'm pretty sure it's caused by that huge backend change I today. I'll release a patch soon, thanks.

>>5071 Do you use a desktop Gopher client? That could probably help to compare results when testing. Lynx is considered one of "the best", OverbiteFF is/was pretty good as a plugin for Firefox but it's not compatible with 57 yet.

>>5072 idk, I just did apt install gopher and that got me a pretty easy to use client, so that's what I use when on pc. I don't really use gopher at all tho, to be honest. Kind of starting to get into it, but it's too slow to be a thing I check daily, ykno? What servers do you browse?

>>5075 That might be the UMN gopher client. >What servers do you browse? Floodgap's for sure, they have an auto updating daily news feed, but the topics tend to be more US/North American so it's probably less interesting if you're in Europe. Gopherpedia as a preferred alternative to Wikipedia. My own server is probably my most browsed though sadly. Others may see it as just a novelty but Phourchan (the Gopher /g/ archive) is honestly how I prefer to browse that board. And I wrote the movie time lookup thing after Google retired their light (for Web at least) Movies tool as a replacement for me. While a lot of other stuff on there is mostly novelty, I intend to use Gopher for pretty much anything one would host a website for. That's the point of the Bucky tool, so I can use Gopher to maintain the place but even normal people can access it with their web browser.

Oh soykaf, look if it isn't the latest release of Pocket Gopher! https://github.com/afonsotrepa/PocketGopher/releases/tag/1.2.1 I can't think of any major features that are missing, so I'm going to start working on releasing it on F-droid and, eventually, the google play store.

>>5133 small bug fix for an anon running android 4.4: https://github.com/afonsotrepa/PocketGopher/releases/tag/1.2.2

New release version won't install for me, any idea why?

>>5175 Yeahp, I changed the certificate/signature, so you'll need to remove the previous installation for it to work.

Pocket Gopher has been released on F-droid!!!! https://f-droid.org/en/packages/com.gmail.afonsotrepa.pocketgopher/ Sorry for the ~2 week delay, but it was a rather difficult process getting it on f-droid :/ This should basically be the last version of Pocket Gopher, except for releases to fix bugs and make small changes.

>>5487 I love your app, suggestion for some interesting gopher sites?

>>5818 gopher://gopher.floodgap.com/1/world/last-hit gopher://gopher.floodgap.com/1/new These are all the gopherholes Veronica-2 has recently hit, and ones that were created "recently" (post-1999). There's bound to be something interesting in there.

I'd like to see where this is now and perhaps discuss gopher in general more. I have a website that just serves my articles. How should I go about adding gopher accessibility to it? Also, how easy is gopher to implement in terms of unspoken or defacto standards?

>>10142 I'm a newbie on the subject, but I may be able to say a thing or two about the first section. This very thread caught my attention, and I ended up looking for stuff on the zine, which led me to create an account and my own gopherspace on a server. Please mind that this is knowledge I acquired on the last hours, so someone may want to correct me in some way. Posts on a phlog (something like a blog, but on Gopher instead of HTTP) are basically just plaintext files, which are indexed by a gophermap file which lists your stuff (similar to creating an index.html on the directory's root). The gophermap itself has its own syntax to indicate a link for a specific file, directory, binary etc. I believe serving your articles on a gopherspace would require you to convert them to plain text wherever possible. The rest is basically typing a bunch of stuff on a remote server.

>>10142 I would think the pygopherd gopher server would be the simplest to set up. http://manpages.ubuntu.com/manpages/bionic/man8/pygopherd.8.html If you run a Debian-based Linux box, it's in the repositories: $ sudo apt install pygopherd and then just start dumping files in the default directory /var/gopher. The server will index the directory and serve a menu automatically, but you can also control what the menu lists like >>10143 mentions with a "gophermap" or similar file. gopher://gopher.floodgap.com/0/buck/dbrowse?faquse%201a They'll look something like this: 1Some files<TAB>files 0Article for 2018-08-22<TAB>2018-08-22.txt >Also, how easy is gopher to implement in terms of unspoken or defacto standards? If you're building a client, there's a few things you won't find in RFC 1436 (which defines the gopher protocol): - 'i' type items, which are used for text in a menu. Some old gopher clients often don't handle it properly, but its use is pretty much ubiquitous. - Other non-standard item types which are not as common, but many modern servers will use some them when building menus automatically, such as 'h' for .html files. You can't catch them all, so the best option is probably to make the client customizable, letting the user pick what behaviours or helper programs are used to handle which types. Or just default to treating these like standard type '9' (binary) and downloading them. For a server: - The aforementioned gophermap. How the server picks what files to serve is not part of the protocol. There are other formats besides the gophermap to accomplish the same thing, but this format is very simple and quick to write. - 'moles', which are like CGI scripts. Basically, if a file is executable (+x), the server executes it, passing in some info from the request via environment variables and arguments, and then serves up whatever the mole outputs on stdout. Gopher's simplicity and transparency make it very easy to dissect yourself. Just use telnet, specify the server and then type a / (for the root selector) and enter: $ telnet gopher.floodgap.com 70 / You will see exactly what makes up a gopher menu. If you're using a Gopher client where the URL is editable, just change the first '1' character (the item type) to '0', and the client will happily treat the menu like a plain text file so you can see the same thing: gopher://gopher.floodgap.com/0/

>>10142 >>10169 Also: >How should I go about adding gopher accessibility to it? pygopherd can act as both a gopher and HTTP server. In this case, it's more like adding HTTP accessibility to your gopher. Whenever someone sends an HTTP request to pygopherd, it will build an HTML version of the corresponding menu. Here is a gopher/website that uses pygopherd: gopher://gopher.quux.org http://gopher.quux.org If you would prefer to keep your HTTP server, and just want some parts to be hosted/accessible via gopher, I use a CGI-based gateway named Bucky. It's mainly for the Bucktooth gopher server (which is what I use), but if you don't care about certain features (like the gopher server seeing an HTTP visitor with their IP intact) it should work just fine with any server over normal sockets: gopher://khzae.net/1/bucky http://khzae.net/1/bucky (as a demonstration)

Why don't you catch the intent of links starting with gopher://? so that tbe app will open if I open a gopher:// link

>>10718 Op here again. Hmmm I guess I just didn't think of it. It's probably pretty easy to implement but I just didn't do it at the time. I've basically quit programming and tech soykaf except for my own autistic and secluded fun but I'll accept a commit if someone else writes it or at least writes an easy step by step guide for my disinterested ass to follow. There's also a bug with newer Android versions that leads to annoying jumps when viewing pages but I've been unable to replicate it and haven't found any info online so I'd appreciate help with that too. (There's a bug report open on github about it but I've sadly been unable to do soykaf all about it) If there's some other feature you guys want tell me and I'll see if I can muster up the motivation to go thru the cancer that is android studio to make it happen.

I'll revive this discussion a tad by mentioning in advance that I'm planning to implement my own Gopher server for hosting my own Gopher service. I suppose I should go ahead and wonder what features it should have. Dynamically generating a menu based on directory contents could be interesting, but I question the utility of this feature as compared to simply requiring a menu to be handwritten or generated by another program. If the server doesn't do anything special such as this, though, it's rather boring, wouldn't you agree? What would you want in a Gopher server, asides from the usual qualities of robustness and whatnot?

>>12000 Besides just generating a menu when there is no "gophermap" at all, Bucktooth (the gopher server I am currently using) has a neat globbing syntax, so you can do a hybrid of handwritten and generated: gopher://gopher.floodgap.com/0/buck/dbrowse?faquse%201a This is an introduction to this menu. Here are the files: ?* This is an introduction to this menu. Here are the categories of files: Some pictures: I*.jpg Some text files: 0*.txt But as you point out, this could be handled by another program instead of the server. In that case, you may want to support "moles", which are the gopher equivalent of CGI scripts: gopher://gopher.floodgap.com/0/buck/dbrowse?faquse%202 Basically, executable files (+x) are executed by the server when that files is requested, and the results are sent as the response to the client. Alternatively, you could roll your own extensible handler system like pygopherd does: https://manpages.debian.org/jessie/pygopherd/pygopherd.8.en.html#HANDLERS

>>12000 >If the server doesn't do anything special such as this, though, it's rather boring, wouldn't you agree? Sounds like you have a solution and are looking for a problem. I've come to find that the most interesting, useful and fulfilling projects tend to originate from a legitimate problem. With that said, you're more than free to fuarrrk around with a gopher server just for the fun of it, it's not like PocketGopher was solution to a personal problem, it was just cool to play with the gopher standard and android soykaf.

>>12000 Well, I procrastinated on this longer than I expected. I dislike URLs, so I'll simply tell you that it's port 70 at the verisimilitudes.net domain. For those who don't want to use Gopher to learn of my setup, which I wrote, you may use this URL: http://verisimilitudes.net/2019-03-30 >I suppose I should go ahead and wonder what features it should have. Dynamically generating a menu based on directory contents could be interesting, but I question the utility of this feature as compared to simply requiring a menu to be handwritten or generated by another program. I've grown to like a particular ordering for some such things and organize my files in a flat hierarchy, so this is significantly less useful to me, I find. >If the server doesn't do anything special such as this, though, it's rather boring, wouldn't you agree? What would you want in a Gopher server, asides from the usual qualities of robustness and whatnot? I wrote a very stupid server for now and this has shown me that it's much better to have the server do some processing, such as for line endings and period placement and whatnot. So, having written and so used an unintelligent server, I know now what I want in a proper server.