- I want more gopher servers,

- I want more scripts for publishing to gopher. I really like the descriptions I've read of the phlog software on SDF, but I've never used it.

That's pretty much it. Beyond that, I just want to see more people hosting Gopher sites on their home computers. I want to see more people focusing on substance over style.

@ajroach42 I love the idea of gopher becoming the goto protocol for lightweight microsystems. It's so much less intesive than running a web server and it fits the CLI theme. Spin up a raspberry pi? Gopher it up!

Security/Encryption -
Long term, yeah, this is probably something we need.

I don't know of a way to do SSL style encryption over gopher at this time. I don't know if this would even really be valuable. For my personal use, I'm fine with SSHing to another server, and doing my gophering from there. No one local is snooping, at least.

If you need security, use .onion you know?

@ajroach42 I started writing my thoughts on "NEXT STEPS" for gopher here: gopher://sdf.org/0/users/tomasino/explorations/gopher-application-development.txt

@tomasino @ajroach42

I'm late to the conversation. Can you point me at a quick gopher primer so I can play too?

@RussSharek @ajroach42 the Wikipedia article covers pretty much the whole thing. Open lynx and go to gopher://gopher.floodgap.com and start browsing. SDF.org has a ton of content.

@RussSharek @tomasino

The most recent article on my blog http://ajroach42.guthub.io should be enough to get you started. If not, the tedium article I link to is wonderful.

@ajroach42 @tomasino

Okay, I get it now. I can see where a client that supported markdown would be amazing, and fail gracefully where it wasn't available.

So yes! Security and encryption is something someone can build. Implement it in a way that's backwards compatible. At the very least, it won't hurt anything.

But also, if you need security go use something designed to be secure.

- Gopher + DAT: This sounds absolutely wild and ridiculous. Go for it! I dunno why you'd want that, but if you do, go for it.

- Other Gopher "abuse:
As long as you don't break backwards compat, do whatever.

The Gopher protocol was written in like 1991 or something? And it will run pretty much anywhere.

The protocol is so simple that you can hack together a client in a few dozen lines of whatever.

You can implement clients on 8 bit hardware. It will be faster and easier to use and more accessible than a web browser.

It's been around forever. It's simple. It works well. It provides just enough functionality to get you to your content.

Plus, most modern Gopher servers provide an HTTP gateway. (See http://gopher.ofmanytrades.com)

So even if you think that we should just focus on making the web less antagonistic towards users, we can use gopher as one avenue towards that.

Gopher isn't ever going to replace the web.

That's not my goal. That's not anyone's goal.

Gopher is just a weird little non-capitalist, human scale way for us to publish and consume stuff.

It's fun, it's easy, and it's a weird way for folks (like you and me) to resist, in our own small way, the shit that the big centralized services do, and the things that netflix pushed the w3c in to doing.

I guess I gotta talk about the w3c a second, too.

The modern web is kind of crap. I won't rehash that here, but you know it's crap.

The w3c has moved to make it more crap by bundling DRM in our web browsers, and making it a felony to do security research on browsers that include that DRM.

This is *real* bad.

That's my biggest reason for embracing this gopher stuff.

The w3c sold us out, and the web browser isn't, can't be, truly safe anymore.

We don't need more #DRM in our lives. We don't need more very complex software that no one understands.

Simple software, when possible, is better software.

the #w3c fucked us when they voted to allow #EME without even basic protection for security research.

But before that, Google and Facebook screwed us over by stuffing more and more javascript in to our pages, and normalizing more tracking everywhere.

@ajroach42 time to build some modern OSS gopher clients? I'm in

@remotenemesis :-D That's my hope.

I'm still a few days/weeks away from being able to contribute, but yeah. That's what I want.

I want to see some folks building new libre gopher clients.

Be kind to one another.

Don't worry, we won't break the thing you love.

We're only here because the modern web is user hostile, and modern web browsers do/will have stuff in them that makes it a felony to keep them secure.

Tim Burners Lee killed Gopher way back when, and then his bad decisions made the web unsafe, so some of us are going back to Gopher.

@ajroach42 Do you have a list or example of some of the early bad choices? I've had a hard time finding them actually defined, which if it weren't for the fact that very practical & knowledgeable people were stating it, would make it sound like it was just nostalgia. A design document for fixing the web is needed & these early concerns need to be defined to help.

@Sci most of the bad choices have been recent.

The web was a good platform until it wasn’t anymore.

Recent bad decisions: EME (rendering browsers essentially permanently inesecure to make Netflix happy), allowing css to be, essentially, a complete programming language, stuffing JavaScript in to the browser.

There have been other questionable or shortsighted choices (the use of the anchor tag for links, the competing image tags in early html—the worst one won)

@Sci I fully expect EME to be the worst of these choices, though. It’s going to be bad.

Beyond that, a lot of the bad web decisions were made by browser vendors and web developers, but many of those were pretty horrible too. Cross-site tracking cookies, flash, JavaScript.

The web shouldn’t have ever become an application layer. It should have remained a content delivery platform. Apps should be native, and hook in to the net via apis.

@ajroach42 It's been a long time since I was into the deep technicalities, so I'm playing catch-up a bit.

If I understand correctly, EME renders browsers insecure because it allows a remote vendor to install a decryption module into your browser, which could contain anything including malicious code or security vulnerabilities, yes?

And both CSS and Java because they push browsers beyond just displaying static documents, but allow code execution within them?

@Sci EME is a form of DRM that is/will be/is bundled in to web browsers.

Technically it's sandboxed and tested and should be "safe", but because it is a form of DRM it is protected by the DMCA making the disclosure of security vulnerabilities in the webbrowser that *might* be related to EME a felony.

The w3c was given the opportunity to stop this, and make members provide an exception for security research and/or accessibility. They refused.

@Sci So now every major web browser has a thing in it that it's illegal for anyone to look at, and we don't have even the most basic assurances that someone who discovers a flaw in EME (and there will be flaws) won't go to jail for disclosing it.

CSS and Javascript I'll address separately.

CSS is supposed to define how a browser displays elements on a page. It's now a programming language. Current CSS takes lots of computing power (which is bad) and can be used to hide/do malicious things.

@Sci

Some things are easier and more secure because of CSS3. A lot of things are harder, and more complex (and less secure because they are more complex, if not because they are directly less secure.) This means that you've got to update your hardware more often. Modern CSS techniques also frequently wreak havoc with accessibility, because everyone is trying to reinvent the wheel.

@Sci Javascript.

Javascript is complicated. I am of the opinion that netscape made a mistake including it in browsers to begin with, but that's just me.

All the stuff I said about accessibility and hardware/performance issues goes double for JS.

Except that JS is a full programming language from the ground up. You can run modern applications in it. You can use it to emulate old computers.

IT's neat!

It's also a huge performance and security hole. Malicious JS can cause many problems.

@Sci That is not to say that I think Javascript in general is bad!

I think it's great. Having this almost universal platform for application delivery is really neat!

I don't think it should be required to view a news article, or to log in to mastodon, or send an email.

I think js should be downloaded from your web browser and then rendered in a separate application.

Browsers shouldn't assume Javascript is available. Browsers shouldn't know about JS.

@Sci You want AJAX features in your web page? Great! What you want is no longer a web page, it's now an application. We'll run it in a separate environment.

You want to mandate AJAX features so that I can read your news article or watch your video? That's probably actually sketchy!

And then you've got shit like: https://www.eff.org/deeplinks/2009/09/online-trackers-and-social-networks which illustrates the tracking problem back in 2009. (it's worse now.)

@Sci This is not a hopeless situation. I'm probably exaggerating the potential hazards for the average end user, but also it could potentially get a Lot worse that it already is.

We're basically waiting for one of these things to snap, you know? Things haven't broken yet, but they could without much warning. All the bad things are in place, waiting for a catastrophe.

@ajroach42 Since modern cybercrime is all about finding an exploit and automating it, the hazards for the average end-user would seem just as high.

Thanks for your replies. It's helped frame it a lot better. It's hard to imagine the net as other than an application layer already.

From a utility perspective it makes sense to have the browsers do the heavy processing rather than just using them as UI for remote server apps. But when that code can contain anything, & DMCA stops it being checked.. ugh.

@Sci

IMO, we need more server side code, and more dedicated applications, and less reliance on JS to replace native browser controls.

Have you read this: https://www.baldurbjarnason.com/notes/under-engineering-websites/

It's not directly about the problems of the modern web that I discussed here, but it goes through a lot of the reasons that native browser functions get re-engineered in worse form by valley companies, which is 100% part of the problem.

@ajroach42 @Sci

You mean, like Dropbox being essentially Gopher but poorer?

@h @Sci

Dropbox adds bidirectional sync to their desktop client, which is neat.

Using it through the web browser leaves a lot to be desired.

@ajroach42 @Sci

Well maybe Gopher 2049 should add some of the Dropbox functionality then, minus the Javascript.

#gopher #gopher2049

@h @ajroach42 I don't have experience with Gopher, but from what I read it sounds very similar to FTP in intent. A network of file systems linking to each-other, rather than documents linking to each-other with http.

@Sci Yeah, it's basically a menu system to sit on top of FTP.

here, try http://gopher.ofmanytrades.com

That's a web proxy for my gopher server.

@ajroach42 It does seem so essential and useful, and in the current climate the only thing that makes it a hard sell is that all resources are presented as equal. You can't skin their presentation in standard Gopher, can you?

@Sci Nope!

Well, no with caveats.

We totally could develop a system to let users or servers skin the presentation. Wouldn't even be that difficult.

Clients would have to support it, and we'd need to ensure it was a progressive enhancement, you know?

But I'm not sure it'd be worth it.

@ajroach42 I'm thinking along the lines that if I had two primary forms of content on a Gopher server and wanted to promote one of them over the other, I wouldn't be able to. It's good for library-style access, but not so good for individuals.

Gopher as a supporting layer under http sounds good to me. Automatically display all publicly accessible folders in Gopher-mode. Or go to http mode for more contextual arrangement of resources.

@Sci I guess maybe I don't understand what you mean.

You can control what things display in the menus, and the order that those things are displayed, and the text that is displayed around them. You can also organize your files so that the ones people want are easiest to find.

You can't change the color scheme or bold certain items in the menu, but I don't see what good that would do.

IF you want an HTML document to link to the files, write an HTML doc and serve it over gopher.

@Sci Unless I'm misunderstanding what you mean?

@ajroach42 I was thinking if I were to build something like http on top of Gopher, I'd probably treat the filesystem as a list of unique resources and reference them through it rather than as relative file locations.

I've not had to think in a structured way in a long while, so I'm liable to misuse a lot of terms.

@Sci Yeah, I guess I'm still not understanding your goal at all.

Sorry.

@ajroach42 I suppose I'm viewing Gopher as a concept rather than an implementation of that concept.

@Sci @ajroach42

It's like FTP in the sense that it presents a list of resources available, in a hierarchy that maps almost exactly to a filesystem structure.

It's like HTTP in the sense that it's stateless, and content is served on a per request basis, over one TCP connection.
(the FTP protocol maintains two TCP connections: a control channel, and a data channel)

See gopher RFC1436:
https://www.ietf.org/rfc/rfc1436.txt

gopher URI scheme RFC4266:
https://tools.ietf.org/html/rfc4266

@ajroach42 I can see why they do it. It does mean they, more or less, only have to develop for one platform instead of multiple. Short-sighted but understandable.

I suspect going more server-side in the current climate would make the net even more centralised. Data centres and their connections would be forced to grow, and better cement their positions. Decentralisation first? Which I'd assume would involve improving end-user webserver deployment.

@Sci I dunno if it would actually lead to more centralization.

It depends on if we go with oldschool (PHP and a prayer) server side code or new school (18 containers) server side code.

Deploying apps used to take ten minutes and could be done on super simple shared servers.

See, the problem is scale. https://medium.com/@jkriss/anti-capitalist-human-scale-software-and-why-it-matters-5936a372b9d

Scale is a trap. Build little things, and make them talk to one another.

Decentralisation and more server side code go hand in hand.

@ayy

Everyone is trying to implement it as safely as possible, but we'll *never* know if it's actually safe, because disclosing vulnerabilities in the EME is a felony.

I'm not trying to fearmonger here. Firefox is probably reasonably safe for most users.

But, so long as EME is in the browser, I will trust my browser even less.

@ayy Right.

But untrusted javascript crashes browsers or does malicious stuff all the time.

And then we fix it, because we can do security research on sanboxed javascript.

@ayy Like, you're not going to convince me that any sandbox is safe.

Malicious code can already break out of sandboxes in browsers to OSs in virtual machines, and then break out of those virtual machine OSs in to the host machine OS.

https://en.wikipedia.org/wiki/Virtual_machine_escape

Have a recent example: https://www.vmware.com/security/advisories/VMSA-2017-0018.html

But we only know about these things, so that we can patch them, because it's not illegal to do security research on these platforms.

EME is unsafe. Full stop.

@ajroach42 DeEME when?

@a_breakin_glass what?

@ajroach42 I'm joking about the possibility of an EME equivalent to https://en.wikipedia.org/wiki/DeCSS

@a_breakin_glass oh right.

@a_breakin_glass we'll have that or something like it quick.

Alternately browsers still have an analog hole.

@ajroach42 I'm not sold by any of those arguments, but one possible argument that could be made is that Gopher matches more closely the model of mobile UIs than WWW applications do.

@h How about this:

Gopher doesn't have EME rendering security research in to your browser illegal. Gopher doesn't do arbitrary client side code execution every time you load a page.

And yeah, Gopher will work really well on mobile, when we get there.

@ajroach42 DAT - is that Digital Audio Tape, or something completely different?

@Dustin Nah it's a distributed torrent thing, I think?

Basically, only the owner can update the torrent, but anyone can peer it.

@ajroach42 That makes a lot more sense.

@ajroach42 "If you need security, use .onion you know?" is the wrong way to look at what tor does. We succeed or fail as a herd - tor provides little security unless we provide herd immunity to attacks. The non-security traffic (with the exception of things like bittorrent, which these days there is tribler for anyway) must be routed through tor.

@ajroach42 that said, post EME everything is back on the table that went off as the WWW won. Project Xanadu & Gopher included.

@jeffcliff Project Xanadu!!! What a weird little artifact.

Have you seen the interview Herzog did with that guy?

@ajroach42 i don't know what herzog is so no. It's apparently *still* in active development.

@jeffcliff Werner Herzog is a film maker.

He did a *really, honestly not good* documentary about the internet called Lo and Behold.

The only interesting part was him talking to the Project Xanadu guy.

@jeffcliff @ajroach42
Can confirm, Xanadu is still in active development. I was involved until a year or two ago. (I actually pushed for gopher & IPFS support in the client I was writing.)

There's a web client on xanadu.com right now that works alright. Unfortunately, same-origin-policy really screws with all the attempted web clients, limiting them horribly.

I'm not allowed to release the desktop clients I worked on. Maybe after Ted dies.

@ajroach42 @jeffcliff
But, I reimplemented some of the data structures and such used in the back-end: https://github.com/enkiv2/misc/tree/master/ds-lib

I might write a minimal front-end sometime. Dev was slowed down because Ted kept changing the file format, wanted the desktop UI to be 3d, and all of us were volunteers with day jobs.

@enkiv2 @jeffcliff Ted seems like a pretty interesting, frustrating dude.

@ajroach42 @jeffcliff
Absolutely. (He's also very theatrical. That comes out in his lectures, but he's like that even in informal contexts.)

@jeffcliff @ajroach42
It was a pleasure and a privilege to work with him, but it was pretty stressful at times!

@enkiv2 @jeffcliff I can imagine!

I'll have to ask you about that sometime.

@ajroach42 @jeffcliff I haven't seen what Herzog did, but this is an interesting Ted Nelson interview with Leo Laporte.

https://www.youtube.com/watch?v=k1QjcUbku6Q

@jeffcliff @ajroach42 I'm working on something tangentially related, by the way.
(been at it for the last couple of years)

@h @ajroach42 ??

@jeffcliff @ajroach42
I'm doing something tangentially related to Xanadu, that is. Borrowing some ideas, not all of them. Ted Nelson is not an engineer or UX designer, some of the things he wanted to do in the 1970s look cool on paper, but they don't work very well for humans, or for real world computers.

That being said, brilliant guy, brilliant vision.

@h @jeffcliff He seemed it in the interview I saw.

But other than the bit with him, the movie was essentially garbage, IMO

@ajroach42 @h @jeffcliff a side-ish note to this thread: i strongly encourage anyone reading who hasn't picked up _computer lib/dream machines_ to find a copy somewheres.

i got it on interlibrary loan some time late in highschool or early in college and it's shaped all my thinking since (even if i think nelson was wrong about a gazillion important things).

@brennen @ajroach42 @jeffcliff

Also recommended:

1. Memory Machines: The Evolution of Hypertext, by Belinda Barnet https://www.amazon.com/Memory-Machines-Evolution-Hypertext-Scholarship/dp/0857280600

2. Bootstrapping
Douglas Engelbart, Coevolution, and the Origins of Personal Computing, by Thierry Bardini
http://www.sup.org/books/title/?id=308

@jeffcliff @ajroach42 @brennen

3. Computer Lib/Dream Machines, by Ted Nelson (PDF scan)

https://www.scribd.com/document/244137228/07-Ted-Nelson-Computer-Lib-Dream-Machine-pdf

WARNING: THESE BOOKS ARE DANGEROUS, THEY CAN ALTER YOUR MIND AND CHANGE YOUR LIFE FOREVER.

@brennen @jeffcliff @h @ajroach42
Computer Lib/Dream Machines is back in print -- Ted found a scan on a pirate site and republished based on that -- but it's expensive (like $50-100). Recommend reading it even if you don't buy it. Copies of the original run are horribly expensive, since it was out of print for 40 years.

@enkiv2 @brennen @jeffcliff @h boingboing posted a link to a copy on archive a few years ago and I printed five or six.

It's neat. I don't know that I ever read it all. I also don't know that I ever connected it with Xanadu in my head.

@ajroach42 @jeffcliff My main disagreement with Nelson, however, is that his original vision of Xanadu contemplated royalties for works published online and tight copyright tracking.

He envisioned that in 1965 when the world was a lot different, it may have seemed übercool at the time in liberal arts school, but I don't believe in intellectual property in 2017.

@h @ajroach42 we are together on that one i think.

@h @jeffcliff

See, that's what I'm talking about. IP is outdated.

@h @jeffcliff @ajroach42
Transcopyright is valuable since it brings in the squares. Basically, the idea was to avoid what happened to Napster when integrating stuff owned by major publishers. (Nevermind that it would obviate the publishing system entirely -- they wouldn't notice for twenty years, so it wouldn't matter.)

@ajroach42 @jeffcliff @h
It's not so much "tight copyright tracking" as using existing space-saving and attribution mechanisms to also support micropayments. The big deal was attribution as a means of tracing context and saving space, and micropayment support was a carrot for big business.

(Medium is doing something sort of similar now.)

@enkiv2 @ajroach42 @jeffcliff The whole micropayments thing is bunk if we're aiming for a post-scarcity economy, and we are already building financial systems around cryptocurrencies anyway, so all that's needed is gateways that connect hypertext to those systems. Much like the way the IPFS guys are working on.

In content-addressable systems that provide immutability plus something like IPNS, attribution is trivial to build upon.

@h @enkiv2 @jeffcliff current cryptocurrency implementations are bad; though. Too much power wasted. They anti-scale.

@ajroach42 @enkiv2 @jeffcliff
I understand the critique that use of energy is far from optimal, but I think that argument against can't sustain itself in terms of efficiency alone.

My points are:

1. Every worthy invention has been far from optimal in the beginning.

2. The depth of the invention of cryptocurrencies in economic systems is only comparable to the invention of numbering systems, an angular moment in history.

(cont'd)

@jeffcliff @enkiv2 @ajroach42

3. The cost of energy is preferrable to the human cost of slavery in the gold mines. Few liberal detractors (like Krugman) are concerned about slavery, but they love their gold just as much as the Austrians do.

4. The state of the art in cryptocurrencies is evolving towards Proof-of-Cooperation, Proof-of-Stake, and even
Tokenisation. The dependency on mining is waning already and the arbitrary inflationary limits Satoshi imposed are a thing of the past.

@h @jeffcliff @ajroach42
I dunno, man. Seems like a system like transcopyright (where proof of work is authorship) gets the incentives closer to correct.

@enkiv2 @h @jeffcliff I don't know enough about how Xanadu handles copyright to participate in this discussion in any meaningful fashion.

@ajroach42 @jeffcliff
As far as I'm aware, no proposal for transcopyright makes use of a blockchain-backed coin -- in part because the proposals aren't for distributed systems. We just use an arbitrary token valued against money we hold in escrow (like, monthly subscription payments or whatever). The business model is that we skim a processing fee when people cash out. So, that part isn't complicated.

@jeffcliff @ajroach42
As far as valuation goes, it works like this:

All copies of a piece of data come with attribution about where it was originally from. Whoever owns the original copy gets to choose a rate (at tokens per character or tokens per byte or whatever). Default is free.

When somebody views the chunk of data, they pay whatever out of their account held in escrow, to the original poster. It's added to their cache & served from there.

@ajroach42 @jeffcliff
Once you have viewed something, it's in your library and you can do whatever you want with it, including posting a modified copy. Since all the parts of the original are still pointing to the original, there's no legal issue: you will get attributed only for the parts of the remix you created and all the samples will get handled properly.

(So, it's valuable for both academic publishing and the music industry, since sample or quote driven stuff is common & a PITA.)

@enkiv2 @jeffcliff I'd have to think about this system more to really decide how I feel about it.

Based on the way you're describing it, it sounds sensible enough, but also it sounds like it would result in copyright maximalism and the erosion of fair use, both of which are Real Bad.

@ajroach42 @jeffcliff
Well, the 'copyright' portion of transcopyright is a misnomer. This is a licensing system, and it differs significantly from all implementations of vanilla copyright.

For instance: nobody can deny someone the right to use a work or remix it (whereas all copyright systems support that); all costs are made explicit at creation time and held consistent; fair use is functionally "whatever would be easy enough to make from scratch that somebody does".

@jeffcliff @ajroach42
It depends upon copyright, the same way that the BSDL depends upon copyright, but its a purely technical solution & not at all a legal construct.

@enkiv2 @jeffcliff @ajroach42 hmm - this sounds very much like a reworking of the old Prestel/BTX (possibly some bits of Minitel?) where there was a cost for viewing some Viewdata pages (usually finance related info), except instead of the escrow/cryptocurrency/whatever it went on the endusers telephone bill..

@vfrmedia @jeffcliff @ajroach42
This was first pitched in the early 1960s. The ACM adopted it in the early 90s, in theory (but as far as I can tell they never got around to building an implementation).

@enkiv2 @vfrmedia @jeffcliff again, this is one of those things that sounds pretty reasonable the way you're presenting it, but I can't even begin to imagine what it would look like in practice.

@ajroach42 @vfrmedia @jeffcliff
Yup! It's never been done at scale. (The only full implementation I'm aware of, with users and such, is tokencoin, which probably doesn't exist anymore.)

Structurally, it's really similar to some of the music industry's standardized agreements for mechanical reproduction royalties.

The big difference is that it's integrated into the editor and the browser, which means it's harder to slip under the radar.

I can think of 5 or 6 possible abuse vectors rn.

@enkiv2 @jeffcliff @ajroach42 at least the "charging/micropayment" bit certainly did get implemented with, European Viewdata systems; the #ccc exposed a vuln in the German #BTX by using a script and a banks hacked ID to call up its own high cost finance info pages (although the result was merely embarrasment as a content owner isn't charged for accessing their own content).

@vfrmedia @jeffcliff @ajroach42
Yeah, micropayments per page are all over the place. Piecemeal fetching is a pretty vital aspect here though.

@enkiv2 @ajroach42 @jeffcliff tfw you invalidate the client's cache to grab some more of the client's cash

@aeonofdiscord @ajroach42 @jeffcliff
That's not one of the possible abuse vectors. The authority that handles the escrowed money keeps track of who has the rights to what byte sequences, and so redownloading is free.

@enkiv2 @aeonofdiscord @jeffcliff otoh, that authority also knows everything you've ever accessed, yeah?

@ajroach42 @aeonofdiscord @jeffcliff
Yup. It's not a distributed system.

(We wanted to be a federated system, with the Xanadu-owned part established first and thus having the biggest pot. The mastodon.social of the docuverse.)

@enkiv2 @aeonofdiscord @jeffcliff thanks for the primer. Pretty interesting stuff.

I wonder if 'ol Ted will ever release anything publicly.

@ajroach42 @enkiv2 @jeffcliff https://www.theguardian.com/technology/2014/jun/06/vapourware-software-54-years-xanadu-ted-nelson-chapman

@aeonofdiscord @ajroach42 @jeffcliff
I wrote parts of the release mentioned here. (Not most of it; I only wrote the SOP workaround and modified it to take arbitrary EDLs.)

It's a completely distinct implementation from the current web client, although it's visually similar.

@enkiv2 @ajroach42 also I've just found this, which is amazing https://www.youtube.com/watch?v=Bqx6li5dbEY

@aeonofdiscord @ajroach42
In case you haven't already seen it (because even people who know about xanadu often don't know about zigzag):
https://www.youtube.com/watch?v=YWDh7TwaaxU

(This is the system that underlies the layout engine in the various 3d clients, in addition to being a nice personal organizer/mindmapping thing)

@enkiv2 @ajroach42 I'm gonna be honest, this website feels a bit time cube

@aeonofdiscord @ajroach42
Yup.

@enkiv2 @ajroach42 so is it just linking symbols together, or is there content attached to the symbols?

@aeonofdiscord @ajroach42
You've got a collection of cells (which can have some content). The cells aren't the interesting part. The interesting part is that a cell can link to other cells along an arbitrary number of dimensions, each with a name. So, most of the information is structural, and invisible -- generally speaking, only two dimensions of connection are visible to the user at any given time.

@enkiv2 @ajroach42 is there a way to surface the names? in the biochem example it seemed like you have to infer the meaning of the links from context

@aeonofdiscord @ajroach42
You can't really see it in the video, but there's a compass in the corner of the window that shows which two dimensions are visible.

Depending on the implementation you're using, there might be a chooser for picking which dimension you want to switch one of them with.

@ajroach42 @aeonofdiscord @jeffcliff
Most of the stuff developed at Autodesk in the 80s was released as open source in 1999. It's a little glitchy, but you can build a client and a server from the udanax green source and it runs.

The client demo from 2008 used to be sitting on the xanadu.com site, but currently I think only the web client is there.

@h @jeffcliff @enkiv2 and when we have a stable, widely adopted crytocurrency platform that isn't killing our planet, I'll be all for it.

I'm in favor in theory, but the execution has a ways to go.

@ajroach42 @jeffcliff @enkiv2

Okay Andrew, I thought you were serious. Please have fun with your stable, widely adopted Gopher, and the widely adopted imperial US dollar.

@h @jeffcliff @enkiv2

Damn dude, why you gotta drag me like that?

Current implementations of cryptocurrency, at least every one that I'm familiar with, were designed to consume massive amounts of power, which I believe is inexcusable.

When we get one that doesn't do that, I'll be more interested in cryptocurrency.

Until then, it's harmful.

@ajroach42 @jeffcliff @enkiv2
That's not dragging you, that's replying to your dismissal on arguments that you didn't address on the merits.
That's how it works, if you demand a serious argument, let's have a serious argument.
You can't leave the discussion halfway with a cold dismissal.

@h @jeffcliff @enkiv2 1) I can do whatever the hell I please, and you're in no position to tell me otherwise.

2) I'm not here to argue the merits of cryptocurrency in general. You came in with that in response to Xanadu's copyright system. I'm not an expert in the field by any stretch, and I don't plan on becoming one. I know current implementations aren't sustainable, and will continue to get worse. I don't know anything about future potentials.

@ajroach42 @jeffcliff @enkiv2

Fine. That's fair and honest. You don't know, that's correct.
Thank you.

@h @jeffcliff @enkiv2 I'm not sure why you're so antagonistic.

We've had a couple of conversations like this, where you drop a lot of really interesting and useful knowledge and then get weirdly defensive and antagonistic when people don't respond the way you want them to.

There's no need for the vitriol.

You're probably right. In the future, cryptocurrency will probably solve a lot of the problems we're discussing here. But right now, it doesn't.

@ajroach42 @jeffcliff @enkiv2
There is no vitriol, no personal animosity of any kind. I don't take debate on ideas as a personal offence. I'm sorry I made the mistake of engaging, supplying interesting information, and trying to reason beyond what currently stands. I'm just turned off by conventional thinking and lack of curiosity, not addressing ideas on their merits.
You're of course not obliged to do anything to match my expectations, that's my fault entirely, and I apologise for that.

@h @jeffcliff @enkiv2

But you just said I was, two or three posts ago.

And I'm not sure how to read the tone of your last several messages as anything other than aggressively and personally antagonistic.

You wanna talk about the merits of cryptocurrency as a solution to modern copyright or whatever? Great! But that's not what I was talking about, and it's not something I'm really interested in today.

@ajroach42 @jeffcliff @enkiv2
I already said sorry for that.

@h @jeffcliff @enkiv2 fair enough.

Next time I have cryptocurrency questions you'll be at the top of my list. I'm sure I'll get around to it in the next few weeks.

@ajroach42 @jeffcliff @enkiv2 Anytime. Cheers.

@enkiv2 @jeffcliff @h

3) I genuinely don't care about cryptocurrency in the slightest at this time, beyond the fact that current implementations are unsustainable.

Like, at all.

You brought it up, as if it was a magic bullet. It's not.

But beyond cryptocurrency not being a magic bullet, I don't care about it at all.

So if you wanna argue with someone find someone else to argue with.

@ajroach42 @h @enkiv2 How widely adopted is widely adopted?

@ajroach42 @enkiv2 @jeffcliff

5. Whilst it's true that the main cryptocurrencies like Bitcoin as they currently stand can't scale to support micropayments (compared to say... Mastercard) that misses the whole point. Capitalists need scale. We don't, we need a million distributed currencies, and thousands of exchange markets to atomise capitalism into human-scale parts.

@h @jeffcliff @enkiv2 @ajroach42

Cryptocurrency energy use isn't an incidental inefficiency that can be optimized away: It's a deliberate anti-feature.

@deejoe Everything is deliberate. Writing software is deliberate. And then we move onto something better.

@h

Immanetize the energy eschaton!

@deejoe Is that English?

@deejoe @h @enkiv2 @ajroach42 It's not an anti-feature so much as a measuring stick for other energy use. Feature, not bug.https://plus.google.com/105395547687614433866/posts/CxjELdkcj2s

@enkiv2 @h @ajroach42 the 'they wouldn't notice for 20 years' might have been true 20 years ago, not so true today. They are getting keen on that sort of thing - cooperating with them to distract them is a tactic that has dubious value.

@jeffcliff @h @ajroach42
Fair. Though, this was the plan as of circa 1960, too -- it just hasn't changed.

@h @jeffcliff Yeah, that's the dude, Ted Nelson.

@jeffcliff Yes, you are entirely correct. This wasn't really about tor, but that's a welcome and valuable point.

@ajroach42 with type 0 like plain text files or you suggest a new type (e.g. m)?

@Dereckson Either?

Markdown files are plaintext files, so I don't mind when I see them published as plaintext files.

@ajroach42 To define a new canonlical type would allow rendering by Gopher clients. To detect markdown to try to render headings, code block, etc. is tricky without any hint (especially as there are a lot of other formats like rst used by Python doc).