Current plans

[ghost]

Development goals

Present concerns

• Completely rebuild UI after port to GTK4
  • Rebuilding UI from Glade file
  • Update code documentation afterwards
• Update workflows to build dependencies
• Tab indicator icons (like showing when audio is playing; toggle mute when clicked)
• Dragging tabs to form new window
• UI element to select native or API-based IPFS protocol handling (perhaps a button with a popover, placed between the downloads and the finder?)
• Switch CLI backend from clap crate to gtk::Application
• Find code should enable or disable some find option buttons based on what's enabled
  • WEBKIT_FIND_OPTIONS_TREAT_MEDIAL_CAPITAL_AS_WORD_START should only be available if WEBKIT_FIND_OPTIONS_AT_WORD_STARTS is on
• Find code should restart search if option buttons change
• Find should implement keyboard shortcuts from search bar
• URL parsing should be handled with Servo
• Experiment with sending IPFS data to scheme handler directly instead of pointing to file
• Experiment with switching from HTTP IPFS API to actual IPFS (http://rustipfs.com/)
• Implement 'New Tab' and 'Error' pages (include in binary)
  • Google Safe Browsing
• Implement what's left from the WebKitGTK programming cookbook
  • Permissions requests
  • Searching text
  • Context menu
    • New tabs
    • New windows
    • Downloads
  • Script dialogs
  • Printing
  • Plugins
• Keyboard shortcuts
• Notifications
• Support for Gemini, Gopher, Finger (it can be done)
• Support for FTP

---

Alpha release

• Tabs
• Branding

---

Beta release

• IPFS directory browser
• User-friendly error pages
• Settings menu
• History viewer
• Extension support
• Bookmarks bar
• Navigation bar pop-ups
• Reading mode
• PDF viewer
• Built-in adblocker
• Back-Forward list when right-clicking navigation buttons

---

Long-term

• Switch to Servo from WebKit (if & when Servo matures)
• Switch from IPFS API + Go IPFS to Rust implementation of IPFS (if & when Rust IPFS matures)
• Implement Hyperdrive support (if & when Rust Dat/colmeia matures)
• Implement Orion WebKit modifications (when Kagi release their changes to WebKit)

[ghost]

Search through page, download referenced IPFS files

Preliminary research: "Web Scraping With Rust" by Kade Killary

Just speculation, haven't really thought this out that well …

1. Grab all hyperlinks, all images, all links (stylesheets, scripts, etc), add them to a vector of strings
2. While iterating through the vector we've made …
   1. Turn relative references into absolute ones
   2. Download all references
   3. Point IPFS references to local cache, push modified page to WebKit

This introduces a greater problem, however, and one that I know we'll have to tackle anyway if we wish to implement more of the browser:
If we're sending pages to WebKit without giving them a path, what will the browser put in the navbar?

The only solution (not really) I can think of at the moment is to store navigation history in a vector of Url::parse-ified IPFS requests.
This is stupid for two reasons:

1. IPFS navigation and HTTP navigation are now handled in completely different ways
   1. This is overcomplicated
   2. This requires more hardware resources
2. Browsing history and navigation history are handled by WebKit perfectly fine as is!

No, I need to think of a better solution to this problem.

[ghost]

Simple solution, we just save to the filesystem!
Let's set up a scheme:

• ${cache_dir}/localgen/IPFS/{CID} - For IPFS pages modified for WebKit

  • Search through page, download referenced IPFS files

• ${cache_dir}/localgen/usr/{page} - For user-facing, browser-generated pages

  • Show directory when giving IPFS directory instead of file (long-term)

  • Handle errors in a user-friendly way (by first public release)

This does conflict with the following goal:

Capture page load event, download IPFS page, redirect from "ipfs" scheme to local cache (implementing IPFS links)

Y'see, having the path to the page within the local cache be uncertain (as it can be within the cache proper, or within localgen) makes achieving this goal extraordinarily difficult and the solution would most certainly be hacky, and I'm not trying to write spaghetti code!

Perhaps overwriting the local cache won't be too bad? I dream that eventually, years from now, browser engines will support IPFS as natively as they do HTTP, because this is too hacky, but it's all I can do!
Why is it that I feel that this will come back to bite me in the arse?

[ghost]

Wait …
Why can't ipfs:// links just be rewritten to point to the local IPFS gateway, if we're parsing for those references anyway?

We can rewrite WebKit's currently loaded contents using

fn load_alternate_html(
    &self,
    content: &str,
    content_uri: &str,
    base_uri: Option<&str>
)

(link)

What we can do with this

• Keep cached data unmodified
  • We can keep pages in RAM, no saving to disk, by using ipfs_download_file to return a String which we can modify in our call to load_alternate_html
• Let WebKit handle caching content
• Show error pages
• Show user pages
• Do all that we planned to without dealing with navbar issues

[ghost]

Directory listing pages:

1. On load request, see if URL is a directory, if it is
2. Save directory as JSON to ${cache_dir}/localgen/usr/dirlist.json
3. Use load_alternate_html to load with directory's URL, but with content from ${project_dir}/dirlist/index.md

[ghost]

New idea for Hive communication: it's more viral. Rather than being able to 'search' for data from a centralized database, or have it fed to you by a central algorithm or intelligence with access to said database, one can 'bootstrap' their connections by finding themselves on an initial page.
This initial page links to other pages, which the user can browse, like Rotonde or Unwalled.Garden.
If anyone wants a map or index of the content available on a platform, they'll have to crawl.

I say this for two reasons:

1. I cannot find out how to replicate the dynamic nature of Web platforms. This 'web-iness' is out of reach
2. There's no reason for me to try and replicate this aspect of the Web. It's better this way
3. I'm not trying to make a new WWW, I'm trying to make a new internet

[ghost]

This is now Ephyra.

[ghost]

• Switch to GTK4 (see example of GTK4 with Rust: GNOME Health)
  • Use GTK4 libhandy to reimplement browser tabs

[emmyoh]

Muddy inspiration:

• Asynchronous collaboration
  • Sharing replicas with other authors, live syncing
• Feeding browser history into LLM, having it recall information (with links)