urbit / aegean Goto Github PK

• Enforce type constraints
  • hops: less than or equal to 2
  • ref: [author=@p date=@da desk=@tas %entry ~]
• Flesh out the evidence type for real
• [%media url=@t] should be [%media url=path] (probably)
• Update JSON parser and agent logic once these types have been updated

Rename %entry to %post. Create a new %entry type that includes %posts and %cards.

%card defines a UI element; other apps will poke in %cards to display info in your feed, and ideally to allow you to send pokes back.

%create currently takes a hops=?(%0 %1 %2) variable, which is too low-level. The caller should specify whether an entry is %local (for this machine only) or %spread (for as many people on the network as the protocol can get it to).

We have the following types:

+$  locker  (map evidence @da)   ::  reported refs from friends
+$  evidence
  $:  mine=signature    ::  [p=@uvH q=ship r=life]
      %disavow
      =ref
      theirs=signature
      =entry
  ==

The vision here is for evidence to get sent around via the %report poke (which currently does nothing), mainly for the benefit of towers flagging malicious users.

This seems straightforward to implement (other than getting the poster's signature). Just need to sit down with tiller and figure out the spec a bit more.

• Update desk.docket with the actual name and description of this app
• Update desk.ship with the actual distro ship
• Update sys.kelvin for 411k and vere-3

• Store targets in state instead of scrying
• Fix move ordering bug where subscriptions get rejected after adding a pal
  • the easy fix here is to allow subs from leechese
  • does gall auto-reject re-subs from the same ship, or maybe the same [ship path]?

There exist three broad categories of "feed card" data structures that apply to capabilities we would like to give publishers to %feed, corresponding to at least three different types of entry:

• Microblog: Small, atomic pieces of content. Primarily focusing on some combination of text, media, and rich links, with some possibility of a reference to another feed entry. We expect these to primarily be authored within the feed app.
• Rich Notification: A non-invasive notification of a happening within another application. Contains some constrained ability for an application to "brand" the card. Can be clicked-through into a native Urbit application, carrying some context along the way.
• Embedded Application: An actionable interface to another application as a resizable "widget" inside the feed.

The "Embedded Application" case, while novel and worth pursuing, is also the most laden with design challenges. Many low-hanging third party use-cases of feed cards fall into the "Rich Notification" category, including "discovery" for many kinds of content that are normally difficult to stumble upon, including:

• Applications
• Groups
• Turfs
• Betting Markets
• Macroblogs
• Shared Files

These types of discovery use-cases do not need a native UI standard to implement, but must provide third-party developers with more graphic flexibility than the basic "microblog" use-case, which are assumed to have a generic theme so that users can submit content with minimal friction. A "Rich Notification" type could look like this:

::  not a spec. just an example
+$  place
  $:
    icon=pith  ::  reference to an embedded image according to content naming standard
    event=@t  ::  what happened? ex. "~hanfel-dovned shared a Group"
    author=(unit @t)  ::  who originally authored the content. ex. ~hanfel-dovned
    title=(unit @t)  ::  title of the thing being shared, ex. "Trent's Group"
    description=(unit @t)  ::  description of the thing being shared, ex. "Place to chat about UI languages"
    action=(unit @t)  ::  what the user clicks through to by clicking. ex. "Join Group".
    ::  note: "clicking through" does not perform a command, but rather goes to the third party application in some context.
    click=(unit pith)  ::  hint to client on where to take the user on-click
    color=(unit @ux)  ::  background color for feed card; if null, white/black depending on system theme
  ==

Implementing this style of feed card would not require a novel native UI system and still allow third party applications to both use the global feed to make their content more discoverable by more-casual users, and allow them to express their visual style of their brands with custom icons and colors. Rather than showcasing unique capabilities of Urbit, this type of feed entry aims to solve a crucial gap in the Urbit UX experience around discoverability.

An %entry is defined as:

+$  entry                    ::  /mar/entry/hoon
  $:  text=(unit cord)       ::  max length 256 bytes
      link=(unit rich)
      quote=(unit ref)
      tags=(set @ta)
  ==
+$  rich
  $%  [%preview =preview]
      [%media =media]
  ==
+$  preview  (map path cord) ::  OGP data
+$  media
  $%  [%url path]            ::  url with supported mime type
      [%scry path]           ::  FQSP with supported datatype mark
  ==

I have a poke defined for submitting an entry:

[%create =entry =hops]

But this is a lot of information for a user to manually submit every time they post, and having the frontend keep track of preferences here and then silently add them into this specific poke every time seems unnecessarily heavy. It seems useful to distinguish between the powerful %create poke that other apps will use, and whatever poke corresponds to the UI interaction of typing something into the text box at the top of the feed and clicking Post.

This poke then should be very heavily informed by what we want the user experience of posting on the feed to look like. Some points to think about:

• When sharing a URL, do you paste in a URL in the URL box like on reddit? Or include it in your text and let the server parse it out, like on Twitter?
• What does sharing content that you have saved at a scry path look like? Like the file browser on your phone when uploading an image? Do we punt on this until we have a native client?
• See #10. Rather than asking the user to specify whether they're sharing a %media or a %preview, we should have them just submit text and parse the link on the backend to figure out what it is.
• Are tags something the user should ever be manually setting?
• Are hops something the user should ever be manually setting?
• Can you quote a post within the Submit Post box, or only via a quote post button on other posts?

Entries should be served piecemeal via a scry (or schooner GET request) that specifies the range of posts that it wants, so that the web page can load more posts on scroll rather than naively asking for the entire post history.

We would like to be able to address content in a general way that provides most of the guarantees of fully-qualified scry paths but can be made useful in environments constrained to HTTP like the browser. With SSO, one can assume that all Urbit IDs have a corresponding public URL that can be resolved by any ship.

There is the possibility of unifying this standard with the idea of a "pretty-path", or the idea of a user-facing scry path that strips some data from the FQSP to be more legible to human eyes.

Example:
pretty-path: ~tiller-tolbus/blog/aegean
FQSP: ~tiller-tolbus/data/~.~2024.2.3..20.12.12..c863/cx/home/blog/aegean/udon
URL: https://tiller-tolbus.redhorizon.com/blog/aegean

In essence, we should try to define a standard in which every piece of content that follows the standard exposes 1) a human-readable address, 2) a way to derive a FQSP, and 3) a clearweb-accessible URL.

This would be helpful to resolve some questions in #11 and #12

You can't get a remote scry at now. How do we handle this? Do we enforce that all scries happen at version 0?

Right now boosts and hidden aren't factored into the way the feed is served to the frontend. This wouldn't be hard to do on its own, but actually, sort is probably the actual data structure that should be served. What does this sorting algorithm look like?

Should maybe serve an individual post at shipurl/apps/feed/ref. This might be useful for quoting and other stuff.

Roughest draft:

We need to define two new implementations and protocols:

Feed

A source of truth that organizes a list of content by @p and @da to avoid colissions (this can be represented in the path)

It should have children that are a set of feed links, also represented by paths underneath a feed-link child

Feed Link

Source

When you write a post, the post goes to the source, which is being mirrored by the feed-link.

• feed

• feed/feed-link/@p

• feed-link
  Feed link is a mirror of somebody's posts

feed
++  kids
%-  (gas by *kids:neo)
:~  [&/%feed-link |/%p %feed-link %feed-link-diff]

When performing a raw clam, use soft to gently handle the case that a type doesn't properly nest.

When a %preview is posted/generated, the frontend should fetch the OpenGraph data from the provided link and store it. This OpenGraph data should then be used to render the rich content for posts with a %preview tag.

• boosts (and maybe reports)
• filter posts by targets only
• upload image box for local data?

%foes needs to be rigorously tested to ensure that it works right.