-
Notifications
You must be signed in to change notification settings - Fork 1
Bounties
Every OS needs a calculator. Abacus will do all calculations in hoon, returning the results to the frontend for display.
Abacus: a basic calculator with the ability to convert units.
- As a user, I want to add, subtract, multiply, and divide numbers.
- As a user, I want to be able to use decimals or enter fractions.
- As a user, I want to type in longer formulas that can then calculate results.
- As a user, I want to convert units quickly
For security, the UI should not send preformed dojo commands to the backend agent, but rather, a series of types that can be deserialized and used to generate hoon expressions that are then calculated.
Holium will work with the developer(s) to provide frontend support, but the team working on this bounty will be responsible for frontend implementation.
Have a working calculator app that can convert units.
For the milestone to be completed, the app must be approved by Holium and it must be hosted for distribution on Holium's app star (as well as your own if desired)
- Hooking into the Realm Oracle for fast access to conversions, and calculations
- Ability to convert currencies and crypto currencies with real time price data
- At least one years of professional programming experience
- Experience with full-stack development, including JS and some server-side language
- Graduated from Hoon school
Group chat and DMs are a type of database. It is a collection of images, links, news articles, and commentary. Much of this gets lost in the ever growing feed. What if there was a way to surface relevant information in different types of views? This project hopes to enable that sort of functionality by providing a way to view all news links in a new reader layout.
Having a news app that aggregates articles based on your interests and the groups you are in would save time from endlessly scrolling back to check for new links in a chat channel. The app would organize the articles by "date posted" in a news feed interface.
chronicle: a news app that surfaces all links from your groups channels and organizes them into a timeline that should look similar to a
newspaper. Imagine Google News, but for your group.
- As a user, I want to view all of my group's chronicle data in an aggregated view.
- As a user, I want to be able to save to a link to a reading list.
- As a group member, I want to view only my group's chronicle.
- As a group member, I want to be able to upvote or downvote a link, which would allow for ranking articles.
- As a group admin, I want to be able to "feature" an article that I feel is relevant to my group.
Considering groups are being refactored, this bounty is contingent on getting looped into the development releases of new groups in order to surface the data effectively. Modeling this on old groups will not achieve the goal of this bounty.
Once the new channel format is determined, the goal is to watch for updates of the new group/channel agent and parse out any {link: "<- some link->"} from a post contents and add it into the chronicle store with any metadata necessary (date, posted by, included comments).
The backend agent should store chronicles per group (or space) path (i.e. ~lomder-librun/my-group). If the new channel format does not support the same graph-store like path, we would need to generate one in this format.
Upvotes and downvotes would also need to be stored per link which can then be used for a scry that would rank links by day, week, month, and all time.
Have a working news app with a UI that accounts for all of the requirements listed.
For the milestone to be completed, the app must be approved by Holium and it must be hosted for distribution on Holium's app star (as well as your own if desired)
- At least one year of professional programming experience
- Experience with full-stack development, including JS and some server-side language
- Graduated from Hoon school
Engram is a knowledge management application that allows individuals or teams to build rich note documents.
Right now, the only way to collaborate on documents in Urbit is in the notebook channel via comments. There are no features around knowledge management, tagging, history, or any feature required for collaborating on documents with others. The goal of this project is to provide a robust solution for groups or individuals to collaborate on documents.
For V1, Engram will focus on enabling rich document editing for an individual experience, but multiple collaborators. Different people should be able to modify the documents based on permission.
There are several features and agents that may need to be created to support this.
- Document editor
- Git-like revision history
- Inline comments
- Sentence parser for storing each sentence as a node in a graph for easy referencing, commenting, and more future features.
- Document permissions
As a single user, I would like to:
- See a list of documents for my own ship context.
- Be able to edit a document myself.
- Have others invited edit the document
- See a history of changes on the document.
As a group member, I would like to
- See notes associated with my group.
- Be able to comment on sentences at the current revision.
- See a log of changes via a pop-out panel
- Be able to resolve conflicting revisions.
As a document editor, I would like to:
- Have the current document state saved in local storage if I haven't clicked save and accidentally close the tab.
- Be able to edit in readme mode
- Be able to edit in preview mode
- Have a hoverable style block appear when editing
- Add collaborators to the document with an edit permission or view permission.
As a document viewer, I would like to see
- A rich document with formatting.
- A list of authors and editors.
- View comments on the document .
- View phrase comments on sentence hover.
- Have custom embeds in the document:
- code block
- link
- video
- image
The most complex part of this is the revision log. It should be easy to revert to a certain point in time. There will also need to be a sentence parser that stores each sentence in a store with associated comments and other metadata. Each sentence or collection of sentences should be able to be referenced by other documents.
Holium will work with the developer(s) to provide frontend help.
The first milestone is to release a version of the app that allows for single user documents, meaning there is a document owner and only they can edit it. The app should include the rich document editor features without collaboration.
The app should be released.
This second milestone is building out the revision history log to allow for undo, redo, and time traveling through revision snapshots. This will serve as the foundation of the third milestone.
There should be a revision history log in the UI that allows users to go back to previous snapshots as well as the ability to leave comments on the document or on sentences.
Allows multiple editors to modify the document and resolves the differences between the documents. There is not a need for live co-editing in this milestone as that is reliant on WebRTC or another streaming solution.
You should have the ability to add new users to the document, manage those users permissions, and remove the users from the collaborator list.
There is the potential for several future releases enabling more collaboration features:
- Public pages
- Live co-editing (WebRTC or Urbit native)
- Group-to-group document sharing (if groups enable)
- Inter-document referencing (hypertext-like)
- At least three years of professional programming experience
- Experience with full-stack development, including JS and some server-side language
- Demonstrable experience with writing Gall agents
- Coordinate with Holium on designs, frontend, and agents
This project has many pieces and would likely require a team size of two or more. There would need to be a significant amount of frontend work, which Holium will help build or facilitate using our design system. V1 deadline is 6 months from start.
Different groups may have different definitions for words. They may make up their own words or give words new meanings within the context of their group. We want to support the ability to manage these group-specific lexicons, while also allowing for displaying standard definitions.
Lexicon: urban dictionary for communities. Should allow for the user to create custom definitions.
- As a user, I want to view my group's lexicon.
- As a user, I want to add a new word to my group's lexicon
- As as user, I want to add a definition to a word already added to my group's lexicon
- As as user, I want to add an example sentence to a word already added to my group's lexicon.
- As a user, I want to upvote or downvote a word, definition, or example sentence.
- As a user, I want to search for words with a search bar
- As a user, I want to view standard dictionary definitions when a word has been added by my group.
The backend agent should store words per group (or space) path (i.e. ~lomder-librun/my-group).
There should be a map of words that then have an array of definitions that are sorted by the number of upvotes / downvotes. The ability to add words or definitions should be able to be permissioned based on the following:
- member
- admin
- moderator
For example, a group may allow members to write definitions, but only admins can add new words. This should be able to be configured by the admins or owner.
The agent should also query out to https://dictionaryapi.dev/ if a word is not found in the word map.
Holium will work with the developer(s) to provide frontend support, but the team working on this bounty will be responsible for frontend implementation.
Have a working dictionary app that fulfills the user stories above.
For the milestone to be completed, the app must be approved by Holium and it must be hosted for distribution on Holium's app star (as well as your own if desired).
- Publicly permission words so groups can link their lexicons to each other.
- Hooking into the Realm Oracle for quickly searching words
- At least one year of professional programming experience
- Experience with full-stack development, including JS and some server-side language
- Graduated from Hoon school
In order to make Urbit feel like an actual OS, we need minesweeper.
Minesweeper: a redesigned version of minesweeper where all of the game logic is written in hoon.
- As a user, I want to be able to set the game difficulty (see below table)
- As a user, I want to be able to experience the classic minesweeper game interface, but redesigned.
- As a user, I want to be able to see previous scores (personal leaderboard).
- As a group member, I want to be able to see scores of other people in my group.
- As a user, I want to make a custom difficulty level, entering height, width, and # of mines.
Game state will be kept track of in a backend agent. The UI should only render the current game state and send moves to the agent. There will be a few types in the agent state: game-state, settings, leaderboard.
The leaderboard can be shared with others in your group, which would allow a group leaderboard to be generated. A ship can set permission of if it wants to sync its local leaderboard with the group host.
Holium will work with the developer(s) to provide frontend support, but the team working on this bounty will be responsible for frontend implementation.
Have a working minesweeper game with requirements listed.
For the milestone to be completed, the app must be approved by Holium and it must be hosted for distribution on Holium's app star (as well as your own if desired)App must be finished.
tomeDB is a javascript library and a gall agent. The javascript library implements data contracts defined by a gall agent so frontend developers can store any key-value pairs, logs, feeds, or files.
The current @urbit/api library does not achieve this goal as it is too tied to Landscape.
There are two portions of this project:
-
@urbit/tome-db: a javascript library that implements the%tome-apipokes and scries. These pokes and scries follow a standard format. - tome gall agents: the main gall agent that handles the
@urbit/tome-dbrequests, checks permissions, and relays data calls from the various store agents. Access controls are handled in%tome-api
An implementation of the tome for connecting from javascript. When a developer initializes a tome instance in javascript, the expectation is that all access-controls are handled by the lib. There should be a way from javascript to define a new store, pass permission options, and be able to interface with each store type.
A gall agent that handles the javascript lib requests and manages permissions.
There are three storage types that can be initialized through %tome-api, these handle all updates to subscribers through a common
permission system.
-
%tome-kv(key-value): used for storing app data, configuration data, settings, etc. -
%tome-log: an immutable log (append-only). Good for message queues, revision logs, etc. -
%tome-feed: a mutable log where entries can be added or removed. Can be used for feeds, chats, blog posts, etc. -
%tome-blob: stores metadata and hashes for IPFS files.
A simple key-value store.
- set
- get
- remove
- all: returns all key-value pairs
- clear: clears the entire store of all key-value pairs.
An append-only log.
- add: inserts an entry to the log
- get: retrieves a single log entry
- window: retrieves a list of entries by index. By default retrieves the most recent.
A mutable log.
- add: inserts an entry to the log
- get: retrieves a single log entry
- revise: adds a revision to a log that has already been added.
- remove: deletes an entry from the log
- window: retrieves a list of entries by index. By default retrieves the most recent.
- Stores a file in IPFS and stores the hash and metadata in a simple hoon store. It should also handle caching files on the client so they only are loaded once, unless the hash changes.
- store: sends file to IPFS via client and stores hash in %tome-blob agent
- edit: updates file metadata
- delete: deletes file from IPFS and metadata record from %tome-blob store.
- open: anyone can watch a store
- invited: only a list of invited @p's can watch a store
- group: all group members can watch a store
- our: only
our.bowlcan access the data.
For this milestone to be complete, there needs to be:
-
%tome-api: implements the api layer for handling requests from the UI and pokes/watches from other ships. Also, this should implement permissions. -
%tome-kv: an agent that stores the key-value pairs. Should not need to know about permissions. Can only be accessed by host ship.%tome-apidoes all of the permission checking and subscriber management. -
@urbit/tome-db/kv: implements the%tome-kvfunctionality in the javascript library to allow UI developers to easily store strings, objects, arrays, etc. against a key.
For this milestone to be complete, there needs to be:
-
%tome-log: an immutable log (append-only). Good for message queues, revision logs, etc. -
%tome-feed:a mutable log where entries can be added or removed. Can be used for feeds, chats, blog posts, etc. -
@urbit/tome-db/log: implements the%tome-logfunctionality in the javascript library. -
@urbit/tome-db/feed: implements the%tome-logfunctionality in the javascript library.
The log and feed implementation will be fairly similar, which is why they are bundled together
- At least three years of professional programming experience
- Demonstrable experience with writing Gall agents
- Coordinate with Holium on designs, frontend, and agents
Having the ability to upload files to a personal or shared file drive is foundational to any operating system. Being that Urbit cannot (as of now) store large files, Trove will leverage third party storage solutions. Groups should be able to add files, manage folder hierarchy, view files and folders, and search for files.
Trove: A shared file drive allowing the upload of files to an S3 bucket or IPFS and the ability to organize the file links in folders.
- As a user, I want to view my files in my trove.
- As a user, I want to add files to my trove.
- As a user, I want to reorganize files in my trove.
- As a user, I want to delete files from my trove.
- As a user, I want to view previews of common image formats JPG, PNG, WebP, GIF
- As a group member, I want to view my group's trove.
- As a group admin, I want to manage permissions for adding files, adding folders, moving folders, and deleting files and folders.
The backend agent should store chronicles per group (or space) path (i.e. ~lomder-librun/my-group).
The backend agent should work alongside a client library to store metadata associated with a file hosting in S3 or IPFS. There would likely be two maps to manage. One being a map of file-url to metadata. The second being the folder structure and which files are in each folder.
The client library will do the uploading to S3 or IPFS and forward the metadata to the backend agent upon success.
Roles are as follows:
- member
- admin
- moderator
A group admin should be able to set roles for the following actions:
- add-file
- edit-file-metadata
- move-file
- delete-file
- add-folder
- edit-folder-metadata
- move-folder
- delete-folder
A set of roles will be mapped to each action as below:
- add-file: {member, admin}
- delete-folder: {admin, moderator}
Holium will work with the developer(s) to provide frontend support, but the team working on this bounty will be responsible for frontend implementation.
Have a working file eHave a working file explorer app that can find files, transfer files, and drag and drop.
For the milestone to be completed, the app must be approved by Holium and it must be hosted for distribution on Holium's app star (as well as your own if desired).
- File tagging w/ lexicon data
- Drag and drop uploading
- Publicly permission folders and files to share with others and link file drives between groups.
- Hooking into the Realm Oracle for quickly searching for files
- Prefer two developers
- At least one years of professional programming experience
- Experience with full-stack development, including JS and some server-side language
- Graduated from Hoon school