@freakazoid @dredmorbius @enkiv2 Is ! still reserved (! may be a DNS thing actually, thinking about it further)?

@dredmorbius @kick @enkiv2 @freakazoid
If you mean ! as in the routing control, isn't that even worse? We probably want to specify *less* irrelevant information by default.

@enkiv2 Bang simply as available notation. Now that I think of it, it might make a good routing _mechanism_ specifier:

!<specifier>=<key>

http://!<specifier>=<key>/<local-part>

Again, I'm not sure this is better than individual protocols.

Another option would be to specify some service proxy, which could then handle routing. URI encoding doesn't seem to directly provide that, apps/processes define own proxy use.

@kick @freakazoid

@dredmorbius @enkiv2 @kick @freakazoid
Bang was used in usenet addresses to separate a series of hosts in order to specify a routing, since UUCP would be done by machines calling specific other known machines nightly over landline phones. You'd see bang routing in usenet archives as late as the early 90s. I'd be surprised if it's not still theoretically supported in URLs.

@enkiv2 Email also.

I used (though understood poorly) bang-path routing at the time.

So yes, I'm familiar with the usage and notation. The question of whether or not it's appropriate here is ... the question.

At present, HTTP URL's *presume* DNS.

The problem is that DNS itself is proving problematic in numerous ways, that ... don't seem reasonably tractable. The dot-org fiasco is pretty much the argument I've been looking for against the "just host your own domain" line.

@kick @freakazoid

@enkiv2 That's at best worked with difficulty for large organisations -- domain lapses, etc., occur with regularity.

Domain squatting, typosquatting, and a whole mess of other stuff, is a long-standing issue.

In that light, Google's killing the URL _might_ not be _all_ bad, but they've been Less Than Clear on what their suggested alternative is. And I trust them less far than I can throw them.

For individuals, the issues of persistent online space is a huge issue.

@kick @freakazoid

@enkiv2 Then there's the whole question of how many spaces is enough. There are arguments for _both_ persistence _and_ flexibility / alternatives, and locking everyone into a _single_ permanent identity generally Does Not End Well.

The notion of a time-indexed identity might address some of this. Internet Archive's done some work in this area. Assumptions of network immutability tend to break. In time.

@kick @freakazoid

@dredmorbius @enkiv2 @kick @freakazoid
Yeah. Any immutability needs to be enforced because when the W3C declared that changing web pages is Very Rude all the scam artists & incompetents did it anyway. Content archival projects like waybackmachine become easier if you have static addresses for static content & some kind of mechanism to repoint at a different set of static documents (like IPFS+IPNS).

@enkiv2 I'd argue that there's a place for redacting content -- see the Bryan Cantril thread from 1996 previously referenced. That's ... embarassing. Not particularly useful, though perhaps as a cautionary tale.

There's a strong argument that most social media should be fairly ephemeral and reach-limited.

There are exceptions, and *both* promiting *and* concealing information can be done for good OR evil.

@kick @freakazoid

@dredmorbius @enkiv2 @kick @freakazoid
In terms of negative feedback -- I don't consider redaction of already-published material to be the best or most useful form. We see problems that could be solved by this, if mirroring & wayback machine & screenshots didn't exist. I'm more hopeful about solving the dunking problem with norms.
Reach is a lot more nuanced & powerful. Permanent & reach-limited like SSB feels like the right thing for nominally-public stuff.

@enkiv2 @dredmorbius @kick @freakazoid
(Secret stuff is a different concern. Encryption gets broken. Accidentally leaking secret info publically is a problem but giving up all of the benefits of staticness -- mostly making decentralization viable -- won't solve the whole problem and also IMO isn't worth it for the few cases it does resolve.)

@enkiv2 For ordinary citizens, the ability to unpublish / recall content seems fair -- that's the EU's RTBF.

For organisations, governments, highly significant individuals, criminals, and others with significant social obligation or power, the ability to capriciously unpublish is much more problematic.

The nature of online communications makes what were previously _streams_ into _records_, which can have tremendous durability. Everthing needn't last forever.

@kick @freakazoid

@dredmorbius @enkiv2 @kick @freakazoid
I find RTBF problematic because it's not very useful in the absence of norms against personal archiving (itself a problematic thing). We're better off developing norms about carefully checking the context around claims of wrongdoing before acting on or spreading those claims -- something that becomes easier when public information cannot be modified after publication. That's a tangent even by the standards of this thread tho

@enkiv2 @dredmorbius @freakazoid I need an image macro for "That technical problem is too hard! Let's change the world instead!"

NB. You may very well be right, but it still feels very comical in some way.

@kick @enkiv2 @dredmorbius @freakazoid
It's more a matter of: the social problem cannot be fixed by a technical change, so we should employ a social change instead. No matter what we do on a technical level, we can't really move the needle on this.

@enkiv2 @kick @dredmorbius @freakazoid
Changing norms is harder than employing technical systems because power is not as lopsided. To change norms, you need buy-in from most participants; to change tech, you just need to be part of the small privileged group who controls commit access. This is why it's so important, though. Norms aren't set in stone but they'll only change if you can actually convince people that changing their habits is a good idea!

@enkiv2 @kick @dredmorbius @freakazoid
Most people online have had bad experiences with people weaponizing out-of-context information -- that's why technical solutions like RTBF exist. RTBF not actually working, while simultaneously pushing power into the hands of centralized corporate services, is obvious to most people too. Saying "it's impolite to dogpile on somebody without checking whether or not you've been misled first" is way less extreme.

@enkiv2 @kick @dredmorbius @freakazoid
Re: the speed at which norms can change, consider content warnings. They went from something that only a handful of folks with PhDs trying to work out experimental ways to avoid meltdowns in extreme circumstances having even heard of them to something that everybody is aware of & only jerks believe are never justified in a matter of ten years. We still argue about when they're justified but there isn't a serious contingent against using them at all.

@enkiv2 @dredmorbius @freakazoid CWs were an organic change, first-propagated in relatively insular communities where norms permitted (non-religious) preaching & crowd-shaming. Not sure how that change would go if not sparked in a similar community, but there doesn't seem to be a similar community at the moment.

@kick @enkiv2 @dredmorbius @freakazoid
Well, the communities I had in mind were IPFS and SSB (mostly SSB -- IPFS is much more tech-libertarian with a civil-libertarian streak, while the core SSB developers are very interested in the problem of community norms & how to deal with an environment of high speed off-the-cuff communication with permanent messages).

Sign in to participate in the conversation
mastodon.cloud

Everyone is welcome as long as you follow our code of conduct! Thank you. Mastodon.cloud is maintained by Sujitech, LLC.