@freakazoid What methods *other* than URL are you suggesting? Because it is imply a Universal Resource Locator (or Identifier, as URI).
Not all online content is social / personal. I'm not understanding your suggestion well enough to criticise it, but it seems to have some ... capacious holes.
My read is that search engines are a necessity born of no intrinsic indexing-and-forwarding capability which would render them unnecessary. THAT still has further issues (mostly around trust)...
@freakazoid ... and reputation.
But a mechanism in which:
1. Websites could self-index.
2. Indexes could be shared, aggregated, and forwarded.
4. Search could be distributed.
5. Auditing against false/misleading indexing was supported.
6. Original authorship / first-publication was known
... might disrupt things a tad.
NB: the reputation bits might build off social / netgraph models.
But yes, I've been thinking on this.
Also YaCy as sean mentioned.
There's also something that is/was used for Firefox keyword search, I think OpenSearch, a standard used by multiple sites, pioneered by Amazon.
Being dropped by Firefox BTW.
That provides a query API only, not a distributed index, though.
@kick HTTP isn't fully DNS-independent. For virtualhosts on the same IP, the webserver distinguishes between content based on the host portion of the HTTP request.
If you request by IP, you'll get only the default / primary host on that IP address.
That's not _necessarily_ operating through DNS, but HTTP remains hostname-aware.
@dredmorbius @kick @enkiv2 IP is also worse in many ways than using DNS. If you have to change where you host the content, you can generally at least update your DNS to point at the new IP. But if you use IP and your ISP kicks you off or whatever, you're screwed; all your URLs are new invalid. Dat, IPFS, FreeNet, Tor hidden sites, etc, don't have this issue. I suppose it's still technically a URL in some of these cases, but that's not my point.
@dredmorbius @kick @enkiv2 HTTP URLs don't have any way to specify the lookup mechanism. RFC3986 says the part after the // and optional authentication info followed by @ is a "registered name" or an address. It doesn't say the name has to be resolved via DNS but does say it is up to the local system to decide how to resolve it. So if you just wanted self-certifying names or whatever you can use otherwise unused TLDs the way Tor does with .onion.
There are alternate URLs, e.g., irc://host/channel
I'm wondering if a standard for an:
http://<address-proto><delim>address> might be specifiable.
Onion achieves this through the onion TLD. But using a reserved character ('@' comes to mind) might allow for an addressing protocol _within_ the HTTP URL itself, to be used....
@kick Clue seeks clue.
You're asking good questions and making good suggestions, even where wrong / confused (and I do plenty of both, that's not a criticism).
You're helping me (and I suspect Sean) think through areas I've long been bothered about concerning the Web / Internet. Which I appreciate.
(Kragen may have this all figured out, he's far certainly ahead of me on virtually all of this, and has been for decades.)
@kragen I see a lot of this coming down to:
- What is the incremental value of additional information sources? At some point, net of validation costs, this falls below zero.
- Google's PageRank relied on inter-document and -domain relations. Author-based trust hasn't carried as much weight. I believe it needs to.
- Randomisation around ranking should help avoid systemib bias lock-ins.
- Penalties for fraud, with increasing severity and duration for repeats.
Taking a single possibility (I listed a few) from a thing I wrote to a couple of posts up-thread but didn’t send because I want to hear someone’s opinion on a sub-problem of one of the guesses listed:
Seed with trusted users (i.e. people submitting sites to crawl), rank preferentially by age (time-limited; would eventually wear off), then rank on access-by-unique-users. Given that centralized link aggregators wouldn’t disappear, someone throws HN in, for example, the links on HN get added into the pool, whichever get clicked on most rise up, eventually get their own ranking, etc.
This works especially well if using what I sent the e-mail to inquire a little more about: cluster sorting rather than just barebacking text (this is what Yippy does, for example, and what Blekko used to do), because it promotes niche results better than Google’s model with smaller datasets, and when users have more seamless access to better niches, more sites can get rep easier. Example: try https://yippy.com/search?query=dredmorbius vs. throwing your username into Google. The clustering allows for much more informative/interesting results, I think, especially if doing inquisitive searching.
Kragen mentioned randomly introducing newcomers (adding noise), but I think it might work better still if noise was added to the searches for at least the beginning of it. A single previously-unclicked link on the first five pages of search results?
@kick As little as possible.
I've not participated online under my real name (or even vague approximations of it) for a decade or more. That was seeming increasingly unattractive to me already then. And I'd been online for at least two decades by that point.
Of the various dimensions of trust, anti-sock-puppetry is one axis. It's not the only one. It matters a lot in some contexts. Less in others.
Doxxing may be occasionally warranted.
Umasking is a risk.
@dredmorbius @kick @enkiv2 @freakazoid yeah, although in many ways it's an improvement over Golden Horde society, Ivan the Terrible society, Third Crusade society, Diocletian society, Qin Er Shi society, Battle of the Bulge society, Khmer Rouge society, Holodomor society, People's Temple society, the society that launched the Amistad, etc. We didn't start the fire.
@kragen Of the various drawbacks of the Mongol Hordes, massive mobile technological surveillance was not a prominent aspect.
The Battle of the Bulge and Holdomor societies _did_ benefit from informational organisation. Khmer Rouge and People's Temple may have, and the capabilities certainly existed.
General capabilities began ~1880, again with Holerith, nascent IBM.
@dredmorbius @kick @enkiv2 @freakazoid depending on who you were and where you lived, it was easy to end up with very little privacy after the Mongol invasion. The fact that the technologies employed were things like chains and swords rather than punched cards and loyalty scores was cold comfort to the enslaved. But, yes, I meant that the societies were more regrettable overall, not necessarily specifically along the surveillance axis.
@kragen We're at an age where a chat amongst friends, as here, is creating a distributed global written record, doubtless being scraped by academics, corporations, and state and nonstate surveillance systems.
US phone call history records date to the mid-1980s (if not before). Purchase, social, employment, and location records are comprehensive for at least the past decade, if not five or more.
If privacy is the ability to define and defend limits on information disclosure, there is precious little left.
The information glut is so immense that even multi-billion-dollar-funded state intelligence apparatus cannot meaningfully utilise the information preemptively. And yet those same state actors leak and lose their own personnel and intelligence data. Political organisations have email leaked. Generals and possibly presidents are downed.
@kragen The same state actors drop death on the sky based on cellphone metadata and other data traces.
And those are the ones we think of as the good guys.
China, Saudi, Israel, Russia, and who knows who all else, are doing far worse.
And we're only really a decade in to this brave new mobile-data-surveillance world.
@kick @enkiv2 @dredmorbius @freakazoid OH. I see now. You weren't referring to what Bryan was doing to Dave or vice versa; you were referring to the fact that we are talking about it a quarter century later. Yeah, it seemed like a good idea at the time. 'course, at the time we were only a few tens of millions of Netizens.
Everyone is welcome as long as you follow our code of conduct! Thank you. Mastodon.cloud is maintained by Sujitech, LLC.