Skip to content
Thoughtful, detailed coverage of everything Apple for 32 years
and the TidBITS Content Network for Apple professionals
39 comments

Well-Known Apple Developers Support Manifesto for Ubiquitous Linking

In his 1974 double book Computer Lib/Dream Machines, Ted Nelson wrote: “Everything is deeply intertwingled.” Nelson was, of course, the progenitor of Project Xanadu, the pioneering hypertext system that predated the Web but never saw significant instantiation in a mainstream product.

Without delving into the many and varied issues surrounding the failure of Project Xanadu to fulfill its lofty ambitions, it’s undeniable that it had a tremendous influence on a generation of writers, thinkers, and developers, including yours truly. And while what I’m about to share with you doesn’t attempt anything near the scope of Project Xanadu, it has a similar conceptual underpinning—the desire to encourage connected knowledge and enhance cognitive productivity.

The Manifesto for Ubiquitous Linking, released today and signed by a collection of well-known developers, podcasters, and professors, says:

To help people benefit from the information they process with software, we advocate ubiquitous support for linking of information resources.

That wouldn’t seem like a radical call to action—after all, the Web would seem to offer precisely that. But much of what we do on a daily basis revolves around information resources that are local to our Macs, iPhones, and iPads, where it’s often difficult or even impossible to link information resources. And even on the Web, it’s all too common to encounter sites and apps that maintain a single URL in the address bar even as you switch among email messages, calendar events, tasks, and other discrete objects that should be independently accessible.

Keep in mind, this is a manifesto, not a technology, standard, spec, or product. The Manifesto for Ubiquitous Linking is meant to encourage developers to add linking capabilities to their apps such that every distinct information resource within the app can be accessed via a link. And it encourages users who want to reap the cognitive benefits to request such support from the developers of the apps they use.

A brief aside about those cognitive benefits. We navigate digital information systems in three basic ways: browsing, searching, and linking:

  • Browsing is an information-gathering method that’s essential when you don’t know what you’re looking for, but you’re pretty sure you’ll know it when you see it. However, it’s by far the slowest of these navigational methods, and worse, it’s easy to become sidetracked onto other topics (Squirrel!).
  • Searching is more directed than browsing, at least assuming your search is well-formed for finding the desired resource. In practice, the accuracy of search terms is essential—a poor search drops you back to browsing through the search results, whereas a really good search displays the desired resource at the top of the results. (My favorite systems support what I’d call “one-hit searches,” where your search switches to or displays the desired item, without an intermediate results list. LaunchBar works that way, as did Google’s now-defunct Browse By Name feature; see “Surf Faster in Google Chrome and Safari 5 with Browse By Name,” 6 April 2011.)
  • Linking is by far the fastest navigational method because a single click or tap provides direct access to the resource you want without the need to browse randomly or even scan through search results. But of course, some person or app must create those links and make them accessible in the appropriate context.

Messages link in Calendar eventAll three navigational methods have their place, but macOS and iOS default to browsing, allow for searching, and pay only lip service to linking. There are just a few examples of linking in macOS, such as the way you can click a relationship header in Contacts and choose Show Contact to display the linked contact. Apple has some private linking capabilities, too: if you click a date in a Messages conversation and create an event in Calendar, it will have a link that opens the original item in Messages. Neat, but Apple doesn’t provide an API other developers could use to get such message links or an interface users could employ for copying them. Overall, however, Apple could do much more to help us create links between information resources.

With better support for linking within Apple’s operating system and bundled apps, you could create links to individual items in Notes or specific email messages in Mail. Wouldn’t it be helpful while working on a document to have a collection of links to supporting reference materials in Notes and Mail? What about linking to a particular spot in a PDF in Preview, to a certain page in an ebook in Books, or to a timestamp in a video in QuickTime Player? And with the necessary servers or services in place, you could even share such links with others.

Third-party developers already provide many examples of this kind of linking—this list of apps compatible with the Hook linking utility gives a sense of what’s possible now. Independent—but not yet particularly coordinated—support also explains why a number of the original signatories to the Manifesto for Ubiquitous Linking are developers like Rich Siegel and Patrick Woolsey of Bare Bones (BBEdit), Ken Case of the Omni Group (OmniFocus), Eric Böhnisch-Volkmann of DEVONtechnologies (DEVONthink), Mark Bernstein of Eastgate Systems (Tinderbox), Michael Tsai (EagleFiler), Frank Blome of ProjectWizards (Merlin Project), Brett Terpstra (Marked 2), Angel Vu of Nitro Software (PDFpen), and Brian Shi of CogSci Apps (Hook). Support for linking is a rising tide that lifts all boats.

So what should you do?

  • Read the manifesto and its associated pages. Beyond the technical requirements for what constitutes ubiquitous linking, the motivation behind the manifesto is particularly worthwhile. If you support its goals, you can sign the manifesto as well.
  • Think about your workflow. How often do you browse or search when you could follow a link that you had made or that was made for you? If it’s a lot, perhaps there are ways you could use links to work more efficiently and avoid distractions.
  • Consider the apps you use. Which of them might benefit from linking, both outbound links to data in other apps and inbound links to internal data? Some apps may already have such features for you to explore; if not, file feature requests with the developers and send feedback to Apple.
  • Spread the word about the Manifesto for Ubiquitous Linking to others who might find it a compelling call to arms and benefit from thinking about linking or evangelizing it to others.

Now I need to do my own pondering about how I might include more linking in my life.

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 31 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

Comments About Well-Known Apple Developers Support Manifesto for Ubiquitous Linking

Notable Replies

  1. Hear, hear.

    One of my favourite things is watching lecturer Beck Tench as she literally pieces together her ideas, linking thoughts in Tinderbox connected to DEVONthink notes into a formal set of relationships. Thinking in a set of applications.

  2. What’s the security downside to this? Can an App gather links? Will there have to be an extended set of authorizations for links, starting with the level of control we now have on Notifications?

  3. Well, I wondered how long it would take the world to catch up. Back in 1993 (also pre-internet) I wrote, and published, and sold exactly such a program: Linksware. MacWarehouse carried it for a year. MacWeek gave it a full page review on August 9, 1993. I’ve attached a PDF of the review.
    Seems like the answer is “almost 30 years.” There is no advantage to generating an idea before it’s time. :slight_smile:
    Linksware 1.pdf (591.0 KB)

  4. It’s somewhat ironic that by making info and content more “static,” it allows navigation to be more dynamic, or rather gives the user better access to information, and choice. I’m all in for this reversal of programming trends and products. Obfuscation, intentional and not, is a problem. I fully support the initiative.

  5. Correct me if I’m totally off base but this sounds like a security nightmare to me or as Steve Gibson likes to say ‘What could possibly go wrong?’

  6. Security is always worth keeping in mind, but since we’re not even talking about a spec here, I think it’s premature to worry. The questions that would come up in actual specs or APIs or implementations would seem to be similar to those relating to Web URLs. Perhaps @LucCogZest or @mjtsai have more thoughts along those lines.

  7. Maybe $189 (1993 dollars) was too much for an idea that hadn’t caught on?

    Hook seems to be a great tool too, but $70 is still a bit of change for a utility.

  8. It depends partly on the OS. For this type of inter-app communication to work in macOS, at the moment, requires that user grant the linking software (“LS”) permission to interact with the “apps to link” (“LA”). In macOS the user is requested to give permission when an app ( software) wants to monitor/control another — user can deny the request on a case by case basis. There’s no way currently to parcel off automation only for linking; so LA’s API (e.g., AppleScript though x-callback-url any other API is allowed, the spec does not even specify the API tech, only generally what it should do) is entirely available.

    LS requires getting the name and title of the current resource. This is similar to what time tracking apps (like Timing) might do (to show you a timeline of your activity they log title and file or web paths).

    It is important to note that having a link (URL+name)does not guarantee access to linked data. It’s still up to the software that serves the scheme of the URL of the link to police access. That’s not different from the case before this manifesto. Example: suppose you have access to a full URL of a resource on a Discourse website; it’s up to the Discourse SaaS to decide whether you can access that URL.

    The manifesto also calls for software to provide automation for creating objects and getting their URLs in return, so that the user can automatically create and link at the same time. A use case for this is linking a PDF in one app (say PDFpenPro) to a new note in another app, such as a file in DEVONthink; or the PDF to a new task in OmniFocus. This is already possible with a great many apps. (This is much more general than macOS 12’s Quick Notes, and substantially predates it).

    Returning to the gather links part of @deemery’s post: The manifesto is not a specification for a bookmarking /linking app; so it does not say what happens with the link data. Software like Hook is a linking and bookmarking tool (the stored links). Hook itself does not send user bookmarks to a web server (its syncing is done via iCloud or a user-chosen folder [could be on a USB drive for instance]). However, one could in principle create a general bookmarking tool that sends bookmarks to a service (like Pinboard, Pocket and Instapaper do with web bookmarks); in that case, the user of such software would need to trust the bookmarking service with its bookmarks.

    It’s worth noting, as implied above, that linking automation already exists in many apps (e.g., EagleFiler, DEVONthink , OmniFocus , Drafts, and Things).

    I’ve independently tried to nudge Apple towards providing better support for automated (and UI-based) linking in its (Apple’s) own apps. For instance, whereas Apple Notes does allow one to get the ID of a note, that ID is not guaranteed to persist across a user’s iCloud instances (e.g., different Macs.) Hook gets around this by forming links out of date-time stamps, which is based on Artëm Chistyakov’s solution.

    In terms of technical requirements, the manifesto mentions that software can provide IDs as alternatives to links — IDs can then be the basis for links. And in order to correlate web links with app links, it’s often helpful to expose IDs in links. Some software already does this; manifesto requests more of that.

    Once interapp linking becomes much more common, I’m sure there will be many requests beyond what’s in the manifesto. I certainly have a lot I’d like to see. But even if only the manifesto’s humble requests were granted, I think life on a Mac and iOS would be a lot better :blush: .

  9. It’s delightful to learn about that, Tracy! Were you partly inspired by Sun’s Link Service/Amy Pearl’s 1989 article? I was using Sun workstations at Sussex U and Birmingham (England) U in those days (and a Mac SE/30 at home); but I wasn’t aware of Sun’s Link Service or yours then.

  10. I’m afraid I’m guilty of thinking the whole thing up from scratch. I was not (and still am not) widely read in computer literature. I started programming the Apple in 1978 after buying one and reading “The Red Book”. My programming was entirely self-taught, starting with assembly and moving on from there. It was only several years after Linksware that my “brilliant” idea was hardly the first instance.

  11. Ah… hindsight… :-). The software sold mainly to institutions and governments who could afford it, or so it seems. Equally, MacWarehouse sold it for about 1/2 of my suggested list, and as I recall, I made about $40 per copy.

  12. Brilliant nonetheless. It’s delightful to read about.

  13. Ok, that explains the ‘legitimate usage model’ But we also need to consider attack models.

  14. As much as I truly love FileMaker Pro, I still miss HyperCard, which was shipped free with every Mac. And I’ve always suspected it was a launching pad for the WWW, and I loved the way that you could stack and link cards. At the time, linking was a whole new highway system. And relatively speaking, linking cards also made it great software for presentations. I still suspect that HyperCard was snuffed out to facilitate ClarisWork $$$$ sales.

  15. Thank you for the kind words :slight_smile:

    Stay well!

  16. This whole discussion brought to mind the interesting series of articles by Ted Goranson for ATPM (another blast from the past…) on the history and importance of outliner software.

    I am fuzzily (and probably incorrectly) recalling articles written over a decade or two ago, they were memorable nonetheless. His principal ideas were around the notion of folding and how structuring information of multiple kinds within larger documents including links could mimic human thought and expression.

    http://www.atpm.com/Back/atpo.shtml

  17. Hypercard did open up the universe!
    Just an aside though; If linking were to become more ubiquitous, so to would the issues around links disappearing and going ‘stale’. It would seem that some thought needs to be applied to these issues pretty early in the planning.
    My first thought is that when a missing or stale link is encountered an automatic search would be generated. With some awareness of the context and perhaps some metadata from the original link the search could be focused enough to be useful in many situations.

  18. This would be great… I am a happy Fantastical user. It’s ability to integrate iCloud, Google and Outlook calendars is fantastic, as is the ability to hook Zoom, Teams and Google Meet to Calendar events.

    I often link Reminders and events to email messages, it would be great to be able to access this functionality in Fantastical.

    Apple recently added the ability to add FaceTime calls to calendar events, but only within their own app. I’d also love to see this functionality in Fantastical.

  19. That sound you hear is OpenDoc turning over in its grave.

  20. I could be wrong, but IIRC, OpenDoc was for Macs only, and it was document focused. Developers were turning away in droves from Macs, and they had ramped up full stream ahead and were cranking out stuff for Windows. And MS Office had already pretty much conquered the world. Adobe had stated it would stop updating Photoshop and its other apps for Macs, and other companies were doing so as well.

    At the time, Apple was more than just broke, it was heavily in the red. Steve Jobs, who had just returned to Apple, killed OpenDoc to focus Macs on the recently introduced WWW, communications and multimedia as well as documents that were sitting on your hard drive. The very super cool first version of the iMac and OS X were key to this strategy. Steve repositioned Mac OS as a platform that developers would want to build apps for, and one that consumers would have a lot of options to pick and choose from. He focused on what people would want and need.

  21. (My favorite systems support what I’d call “one-hit searches,” where your search switches to or displays the desired item, without an intermediate results list. LaunchBar works that way, as did Google’s now-defunct Browse By Name feature;

    A few months ago I realized that while I thought I had my Firefox searches configured to use Google Browse By Name, actually Mozilla had killed it some time ago without notice. So I used a different method to re-enable it.

    What I’m seeing now is the quality of BBN results has gone way down: it frequently takes me to the wrong page.

    It used to be that BBN would only go directly to a web page if Google was reasonably sure that it was the right, definitive result. But now it is tending to go directly to a page that is clearly the wrong result, or a case where no result should be definitive.

    For example: the BBN result for “salmon” is Garlic Butter Baked Salmon - Cafe Delites. What, a random recipe for a particular salmon dish is the definitive page for salmon? Tell me I’m not crazy.

    Another example: the BBN result for “refrigerator” is https://www.homedepot.com/b/Appliances-Refrigerators/N-5yc1vZc3pi. It’s like Google is just taking the current top search hit as the “definitive” BBN result. Or is it to whatever site has bid highest for an ad keyword?

  22. I wasn’t aware it was still working at all—what method did you use to reenable it?

  23. Change the BBN URL to http://www.google.com/search?ie=UTF-8&sourceid=navclient&gfns=1&q=query. (i.e., add the ie=UTF-8 parm).

    But then the problem in Firefox is that you can no longer change the search URL it uses except by installing a search engine defintion. So I searched for browse by name at Mycroft Mycroft Project: Browse By Name Search Engine Plugins - Firefox IE Chrome, clicked on the link for Google US (Browse By Name), and then while on that page you can add it as a search engine in Firefox.

    Add the search engine by clicking on the URL so it drops down suggestions. At the bottom is “This time, search with:”. 4th from the right will be an icon to add the search engine for the current Mycroft page.

    Another problem I found is that the URLs for Google I’m Feeling Lucky searches no longer work; instead of going directly to the site, they stop at a landing page. I think this was because IFL was being abused. The work around here is to use I’m Feeling Ducky instead: https://duckduckgo.com/?q=!ducky+term.

    Note: Now I’m really thinking that BBN has devolved into Browse By Ad Keyword.

  24. I was able to install the plugin you mentioned into Firefox, and I could show that it worked by searching for “AppleID” and for “Jamf Now pricing,” both of which went exactly to the correct page I wanted. (Lots of other searches didn’t, including “TidBITS ubiquitous linking”.)

    However, I can’t make the URL you gave work in Brave or Chrome. Everything just results in a Google search results page. Is that what you were saying when you said that Google’s I’m Feeling Lucky no longer works? (But then how does the Firefox plugin work?) The “TidBITS ubiquitous linking” search did work in I’m Feeling Ducky.

  25. BBN and IFL are supposed to do different things. I’m Feeling Lucky always goes to the first hit in the Google Search results. Browse By Name is only supposed to go to a result if what you’re searching for is a “keyword”. So BBN for “TidBITS” should go to the TidBITS site but “TidBITS ubiquitous linking” isn’t a keyword, so it shouldn’t go directly to a site. IFL (and I’m Feeling Ducky" would go there because it is the top search result.)

    (This is because from what I remember, BBN originated as “keyword search”.)

    What I meant about I’m Feeling Lucky is that the IFL URL https://www.google.com/search?q=term&btnI now stops at a Redirect Notice.

    The BBN name URL does work for me (as Browse by Adword) in Chrome. For example, http://www.google.com/search?ie=UTF-8&sourceid=navclient&gfns=1&q=ford goes directly to the Ford page. But it doesn’t work in Safari. I think Safari is cheating, and is rewriting the search as a standard Google search for some reason. Maybe it has something to do with whatever default search engine contract Apple has with Google.

  26. Interesting! That link does work for me in Firefox and Chrome and Edge, but not in Brave or Safari. So yeah, there must be some behind-the-scenes shenanigans going on.

  27. Our lives are full of links. We keep most of them in our head, which is less than idea. As David Allen of GTD fame says “Your mind is for having ideas, not holding them.”

    There is a Tidbits article that has stuck with me through the years where a physician described how he used a Newton to manage his life. Much of the article described how he could carry around reference material (better today) and manage his scut list (to-dos). Buried in the middle of the article is a section titled “Link It All Together” where he describes how he can create a note with links to Contacts, Appointments, lists, etc. “It’s remarkably easy to create all these links.” It seems that in 1998 the Newton could do something I can’t do with the Apple apps on my iPhone today.

    Thanks for the article. I signed the Manifesto.

  28. Apple has some private linking capabilities, too: if you click a date in a Messages conversation and create an event in Calendar, it will have a link that opens the original item in Messages.

    Unfortunately, this has been broken for a while and remains broken in Monterey.

    It used to be in macOS that you could actually drag an email (say with the invitation for a meeting or containing its agenda) onto a calendar event’s info box towards the bottom where it says ‘Add Notes, URLs, or Attachments’ and from then on that calendar item would display a clickable link to that email. This was incredibly useful because not everybody creates calendar items by clicking on the date/time in the email (as the quote above details) they want to link to. At my work, often an invitation will come as a generic Calendar invite, but lots of follow up technical details will be emailed around by other people in other email chains. This calendar linking functionality even held the promise of allowing several emails to be linked to one calendar item because some of us are used to having many emails with technical details related to a single meeting.

    Anyway, unfortunately, this functionality only rarely works these days. I’m not sure if it’s related to true IMAP vs. bastardized Gmail IMAP or if it’s related to shared calendars (Gmail again) vs. local calendar on your Mac, but it clearly no longer works consistently. Even if you succeed in getting Mail to create the link, not rarely will later clicking it just dump you into a Safari window where the “URL” appears to be the text describing the link in the calendar entry. WTH??? To add insult to injury, even when it works it breaks if you then for example use iOS Calendar and tap on the link from there, regardless of the fact that the mail message you linked to lives on a remote IMAP server that both the iPhone and Mac have equal access to. Not even ensuring that the iOS Mail app just downloaded that message and has it displayed will help. It’s just flat out broken with no indication to the user that it cannot be used that way. Quite the opposite in fact, the link being clearly shown as a link just begging to be clicked/tapped.

    If this thing worked the way it should this would be a) incredibly convenient and b) nicely leverage Apple’s ecosystem where one workflow on one Apple device and OS just continues to work seamlessly on another Apple device running another Apple OS. Alas, we’re far from that here. Meanwhile I’m manually adding mail receipt time stamps like 20211210-1456 as ASCII text to my calendar entries so at least I know where to manually find relevant emails required in that upcoming meeting. Lots of silly manual work. Almost makes it feel like it’s 1982 all over again. :rofl:

  29. That’s @ron’s article! A blast from the past…

  30. The questions that come into my mind here are many and varied…

    • Should links work inter-OS’s/platforms, i.e. not just Apple OS’s…or would that be too difficult to implement?

    • Who would be best to implement such ubiquitous linking? (Apple, Google, third-parties…?)

    • How would the code that does the linking be maintained/expanded upon?

    • Would using it be easy enough for most average users, without getting lost in code syntax?

    • Would yet more file formats be required, or could current ones be used?

    • How would personal/private linking be controllably separated from wider linking outside (e.g. web, et al.)?

    …and a heck of a load more!

    Really, if such linking were to become truly ubiquitous, you’d need an independent body to conceive it and maintain/expand it. Like W3C does for the web, or other trade organisations like (off the top of my head) the current Matter and Thread ones for IoT devices.

    Why did Project Xanadu never get off the ground? Presumably a large factor was awful timing, due to the web idea becoming more realised at around the same time, so people were busy focussing en masse with that, rather than the bigger and much more difficult Xanadu ideas. That’s life for many great ideas, unfortunately.
    But also, mainstream commerciality happened fairly soon for the web later on, and that made it a truly viable entity we all count on today.

    Relying on one company to run the show would only end-up in a half-hearted attempt, likely resulting in failure, as it wouldn’t have the interoperability of something like the web.

    The trouble is, the web and IoT have very clear and obvious large scale commercial uses, so companies are willing to throw vast amounts of money at the maintaining organisations for them to get to work, R+D, maintain, expand, iterate.

    While the usefulness of ubiquitous linking would be massive on both personal, professional, and societal levels, is there enough commercial leverage to the idea, to gain traction beyond mainly academia? That’s something I struggle with. And without that, I can’t see it happening anytime soon, unfortunately.

    The only commercial aspect to the Xanadu idea was micro-payments for linking to parts of commercial works (be they academic papers, video content, photos, or whatever). But again, would this be appealing to a wide enough audience? That would obviously depend on many factors in its implementation, but again I struggle with this, as micro-payments have yet to take off on other projects out there.


    (Matter and Thread info here.)

    Thread is a low power, secure and Internet-based mesh networking technology for home and commercial IoT products.

    Matter is a unifying, IP-based connectivity protocol built on proven technologies, helping you connect to and build reliable, secure IoT ecosystems.

  31. I don’t see why not. If an app works on Windows and macOS and has a sync mechanism, why in principle wouldn’t the links to the same data work on different platforms? Apps providing and serving links is not very complicated at all. Apps have an underlying ID for objects they sync. That’s what allows you to be able to modify the object on one device and see the change on the other; and when you delete the object from one device, it gets (or normally should get) deleted across devices. (True, if the developers are not very skilled or projects not well managed, there can be problems. MobileMe was a mess for instance.)

    Who would be best to implement such ubiquitous linking? (Apple, Google, third-parties…?)

    for object based apps, each developer just needs to do their part.

    Files require a bit more work. But cloud services like Dropbox could help, for instance, by providing an API to get IDs and managing deletion and renaming reasonably.

    I don’t see the need for that at all.

    The protocol is a start. app links are served by the local app. Apps already must have mechanisms to gate who can access what data, irrespective of linking.

    The manifesto was proposed in the spirit that this is not really required. No standard, no specific API is required; general principles suffice, as laid out in the manifesto.

    Compare the agile manifesto. There are varying degrees of agility in software development, but its mission has been accomplished: we’ve (devs) have all been affected by agile/lean. Not a perfect analogy, obviously. But it goes to show that change is possible.

    Back to specifics: the most fundamental idea here is to provide Copy Link in UI and via automation. There’s a bit more to it than that (for object creation for instance), but that’s the key idea.

    centralization was a problem. We are not suggesting any centralization or standards.

    I’ve worked in areas where standards were required. (At Abatis Systems corp. [acquired by Redback Networks], I led for a while the element management group of a multi-service router. It implemented a huge number of standards (TCP/IP RFCs and layer 2 stuff), many very complex (which I needed to wrap my head around). That was required. I also worked in ed psychology/tech where standards like SCORM were proposed, not a success story.) What we’re dealing with here is not comparable to either.

    Time will tell. On macOS at least there are already a great many apps whose data are linkable in our sense (UI and automation). Here’s a list we at CogSci Apps maintain: Linkable Mac Apps – Hook.

    Even s/w developers are distributed along the technology adoption life cycle. As consumers vote with their dollars, the laggard developers will eventually follow suite. For instance compare:

    Compare for instance this tweet Andreas Busch works from home :eu::de::uk: on Twitter: “Unfortunately that’s still not possible with my preferred #pdf app, namely #PDFExpert from @Readdle. Hey @Readdle, can you let me know whether and if so when you plan to fully support @HookProductvT? By the way, merry :christmas_tree::santa:!” / Twitter. There are however several PDF apps (like Skim, PDFpenPro and Adobe products) that support both file level links and deep links (latter via automation).

    The list of signatories has been growing ever since the manifesto’s publication. And the manifesto is being discussed (Media Highlights – Linking Manifesto).

    I’m optimistic.

  32. LucCogZest, really great further info, thanks. Especially for those of us (non-coders) previous not familiar with the topic, here. :wink:

    So in a nutshell, this initiative for devs and users is basically (sorry, I love to bullet point!):

    • Getting the Copy Link functionality that already exists for files (objects) to be copyable within apps. Implementation is decentralised, so anyone can already use them.

    • Apps already exist using said functionality, so they have a proven reliability and robust track record.

    • Hope natural technology adoption life cycle push/pull factors, will help influence devs to implement it and thus drive user uptake.

    While links to the object itself is a great start, as the original Xanadu mentioned, wouldn’t more be needed to deep link to items within objects, and then dealing with the issues of items with commercial value (via payments of some kind)?
    Presumably, these are points for later consideration, rather than the immediate need to get basic linking off the ground and truly ubiquitous.

    (EDIT: Hook app does deep linking on some level already, so presumably others could already follow.)

    Anyway, I really hope this succeeds, as it’s sorely needed and something even average users could make use of for basic uses, never mind those doing research work et al.

  33. Bingo. My guess at the time, and still is, that Xanadu focusing on micropayments was not a smart idea by any stretch of the imagination. AOL quickly dominated the early Web. Google was hovering in the background, beginning to crawl every inch of the WWW, as were many other ad networks. And the idea that every document would be preserved, searchable, and everything would be linkable for time immemorial was not realistic, financially or technically. It didn’t address the potential of multimedia online. And there was just about no focus on security or safety. Xanadu might sound compelling and enticing, but it just could not work in the real world. Even what was then unconquerable AOL has just about ended up like Ozymandias.

  34. It’s worth remembering that the ideas behind Xanadu predate AOL and the Web and Google by many years. My suspicion is that we simply didn’t have the processing power (and possibly storage) necessary for something like Xanadu for quite a few years after even the early online services (CompuServe, GEnie, Delphi, BIX, AOL) or the early Web. Xanadu core concepts are probably much more technically possible now (though there would still be scaling issues) but the network effect has ensured that we’re too far down the path with the basic Web to ever implement things like bidirectional links and micropayments at a low-enough level to meet Xanadu’s design goals.

  35. Quite a lot of years. According to Wikipedia (and what I remember reading years ago), the concept got started in the 60’s, before we even had a modern concept of networking, let alone an Internet or Web. The first proof-of-concept implementation was in 1972 - still long before modern networking.

    For reference, Ethernet got started in 1973 at Xerox and became the dominant LAN technology in the 90’s. The first papers that would become TCP/IP were written in 1974, with the first IP standard (RFC 791) published in 1981.

    While it could be implemented today, as you point out, it would be very difficult for it to become popular enough to realize its original goals.

  36. I’ve always thought that a lot of insanely great ideas got started at Xerox, but Xerox never quite realized how important and valuable these ideas and technologies were. Jobs and Woz did, and I’ll bet that there are a lot of people at Xerox who were, and are, dumbfounded that they never imagined the size and depth of the consumer and business markets for personal computers and networking. And how important stuff like the mouse and GUI could be.

    And IIRC, IBM invested a very significant amount of cash in Apple to help get it off the ground, for which they received a very significant amount of stock. They sold it all on the day Apple went public. I can’t imagine how Apple would have evolved if IBM held on to the stock and maybe had a seat on Apple’s board.

  37. I think techies will look back at the era where apps were in silos as an oddity too, where the importance of navigating between data in different apps was not recognized by the OS vendors, and few consumers realized they needed this ability to (along with the other things in the manifesto). As more software developers get on board, and a snowball of consumers start requiring linkability, the pressure will be too strong for the laggards to ignore. (Microsoft Outlook still does not have an API for grabbing links, for instance, but Apple Mail , Airmail and others do. And Outlook email URLs are a joke, they don’t work across OS instances even for same individual. Readdle’s Spark is also a joke in this respect. Their URLs do not expose the RFC-compliant email ID. I guess they want to lock their users in.)

  38. Add Mac’s Open Doc and Cyberdog disasters into the list.

Join the discussion in the TidBITS Discourse forum

Participants