geekgene / mewsfeed Goto Github PK

• Choose a language in your settings
• Language settings saved locally (to localhost or a private source chain entry)
• Translations of all app text into several languages (excluding user-generated mew content)

We need to choose which languages we want to support in the "official" UI, and get translations made of all application strings.

Add a popup with the agent profile when user hovers a mention in a mew

Reduce flakiness of ci tests by:

• Using cachix key with write permission to reduce nix environment setup time keep flakes.lock up to date
• Refactor tests to avoid using sleep() calls (waiting on holochain/tryorama#167)

Yarns threads / gitbranch view

This is taken from the previous project management doc. I imagine this relates to a Yarn thread splitting and two sub threads going in different directions, but will need more clarification.

A user can pin up to X yarns on their profile page. Pinned yarns are displayed prominently on their profile, towards the top of the page.

Always display the identicon of a user's AgentPubKey on their profile page.

This avoids the risk of people impersonating other users by copying their profile name and avatar.

Consider refactoring DNAs to make it as easy as possible to upgrade integrity zomes and port data into a new DHT.

We may not want to facilitate this at all, and instead rely on coordinator zomes fetching the underlying data from a prior versions running cell.

If we did want to facilitate migrating data into subsequent version's cell, I think this means not relying on ActionHash as the "id" for some data, and instead storing a UUID within the Entry, and then linking from a UUID anchor to the Entry itself.

Add a notifications drop-down panel or notifications page linked from the navbar.

This should display a list of recent data changes that relate directly to my agent:

• Mews that mention my profile
• Responses to my Mews
• Licks of my Mews
• Responses to Mews I have also responded to (i.e. activity on yarns I am participating in).

I wonder if this feature is what we really want, instead of #66.

• A mew author should be able to delete their mew.
• Deleted Mews should be hidden in the UI by default.
• When viewing a response to a deleted mew, the original mew content should be hidden by default.

The UX should make it clear that deleting a mew does not actually delete the underlying data.

I think there is an additional pattern for Participation Protocols that doesn't neatly fit into #62, and #63. This is "optimistically" approve a Mew response, but allow people to attach "flags" those responses Flags can then be used to softly filter what content a user sees, or they can be used to issue warrants.

One option could be that the Mew author specifies the types of flags supported for their content, and default filtering rules for different flags.

A page to facilitate the discovery of other users -- particularly for when a user is new to the app, and is not following anyone yet.

This page should be linked to from the HomePage.

The UX should expose some semi-random collection of user accounts, so the user can find a few interesting to them to follow

A page for a single username that displays all agents who have that username.

This page should be linked to from each agents profile page who has that username.

If a Mew is part of a larger Yarn, it should have an icon that links back to the original Mew (in it's Yarn view)

A user can create an arbitrary List which contains a title, description, and list of elements. The elements can be agents, Mews, hashtags, cashtags, or some combination.

• A user's created lists are published on their profile page. Clicking a list brings you to the detail view for that list.
• A user can link to a list from within a Mew

Note: waiting on public release of NomDeNet

Enable username registration (via NomDeNet) as a revenue model, and to manage disambiguated ownership of names

Let's make everything coherent and consistent for the first release. :)

Allow users upload an image as part of their mew.

Overview

• use @holochain-open-dev file-sharing zome
• Enforce a size limit
• Convert image into efficient format and maximum resolution
• Convert image into several different resolutions for efficient rendering

This also opens up the risk of users uploading illegal content to the DHT, which then is hosted by other peers. This is a major concern for a large global DHT and needs to be carefully considered.

Profile avatar, bio, and location should all be optional

Currently a user has to create a profile to use the app. Instead a user should be able to view the welcome screen with content and agents' profiles without creating a profile.

Only when a user wants to react to a mew or create a new one, should they be prompted to create a profile.

I got to here

I got the impression that this was a p2p social network but I can't see anyone?
is there something I'm missing? I don't see any way to paste an invite code or something like that and nothing mentions connecting to a network?

Currently the UI follows a client-server model where it fetches

1. all mews
2. when accessing a page with a mews feed
   and doesn’t manage state in the store.

Todo:
Refactor state management to poll periodically and in pages of 10 mews and maintain global state in the store which mews feeds on different pages access for display.

Details to be specified.

Create a We-Applet front-end for interacting with MewsFeed.

The only difference between the We-Applet UI and the standard UI, is the we-applet allows an individual user to mark their mews as "syndicated to MewsFeed", which will publish their Mews to the global "official" mewsfeed instance.

We may also want to use DNA properties to specify settings for a local MewsFeed instance. For example:

• Syndicate all content to global MewsFeed
• Global Participation Protocol Rules applied to all Mews
• Name for this special mewsfeed instance

Note this depends on #117

Refactor mew input field handling of links such that:

• User types ^label
• Input popup appears
• User enters a URL in the input popup
• ^label becomes the label for a link which points to the entered URL

Currently, mew text is limited to 200 characters in validation rules. Let's add that limit to the UI CreateMewField.

Create chat rooms for pre-defined group of agents to chat together in private.

• Display a link to "start private chat" on a user's profile page
• Add a link to the header navbar: "new private chat" which opens a modal where the user can invite a list of agents to the chat.

We will likely want to use elemental chat or kisuna for the actual DNAs.

It makes sense to split Participation Protocols into a few classes:

• Deterministic rules are defined in integrity zome validation, and thus can prevent non-compliant data from reaching the DHT
• Others are outlined in #63 and #64

This ticket outlines the Hard Rules ruleset. The ruleset should be sufficiently flexible to support a wide range of actual use-cases of rules, without needing to fork the integrity zome.

In order to achieve this, when publishing a Mew, the author must include their chosen Rules for participation. Those rules published in an Entry which must exist on the DHT. Then, upon validation, we do a must_get_ call on the rules Entry, and apply the validation rules specified within it.

Deterministic Rules

• Allow list of types of responses: licks, mewmews, quotes, replies
• Allow list of AgentPubKeys who can respond
• Deny list of AgentPubKeys who cannot respond
• Allow list of words / phrases (lowercase comparison) that can be included in a response text
• Deny list of words / phrases (lowercase comparison) that cannot be included in a response text
• List of "moderator" AgentPubKeys where all signatures are required to to publish a response
• List of "moderator" AgentPubKeys where M of N threshold of signatures is required to publish a response

Architecture

struct Mew {
...
  response_ruleset: EntryHash,
  approval_signatures: Vec<ActionHash> // signed valid actions from the approved_by_agents, where the entry is a MewApproval and the MewApproval's MewContent matches this Mew's content
}

struct ResponseRuleSet {
  name: Option<String>,
  description: Option<String>,
  rules: Vec<ResponseRule> // If *any* of theses rules fail validation, the response is invalid
}

struct ResponseRule {
  agents_allowed: Vec<AgentPubKey>, // block list takes precedent over allow list (i.e. if an agent is both allowed & blocked, they are blocked
  agents_blocked: Vec<AgentPubKey>,
  response_types_allowed: Vec<MewType>,
  response_types_blocked: Vec<MewType>,
  content_allowed: Vec<String>, // both mew content text and content rule are compared as lowercase strings
  content_blocked: Vec<String>,
  approved_by_agents: Vec<RequireApprovalRule>, // require a signature by these agents "approving" the Mew
  approved_by_agents_threshold: Option<u64>,  // None means that **all** agents must approve, Some(u64) means that at least that number of agents must approve
}


struct MewApproval {
 mew_author: AgentPubKey, // author of mew content
 mew_content: MewContent, // MewContent that is approved
 approved_by: AgentPubKey // agent authoring this MewApproval
}

Currently, when hovering over a link in a mew, we display the full URL that is linked to.

Ideally we would display an image preview of the website, instead. This would require fetching the remote site, generating an image, and displaying that image to the user.

Create some documentation to help guide users on how to use MewsFeed.

Ideally we would have a static "complete" version that a user can read through entirely, as well as "snippets" which can be viewed inline while using the app, by clicking a "help" icon.

Interface to run a full-text search on Mew content.

This will require some peers to provide indexing services to the DHT, or provide an elasticsearch / meillasearch instance to the DHT, such that consumer users can query them for search results

• Separate concerns into different zomes
• Split large coodinator zome file into seperate files / zomes
• Attach links to base for faster querying of updates, deletes.

The link in the displayed mew should be clickable and open in a new tab.

It makes sense to split Participation Protocols into a few classes:

• Agent Perspective Filtering rules are defined in coordinator zomes, and can only filter an agent's perspective on the DHT
• Others are #62 and #64

So each agent's personal ParticipationProtocolSoftRules Entry is private on their source chain, and outlines their own personal filtering of their own perspective of the DHT (i.e. what is displayed in their UI).

Possible Agent Perspective Filtering Rules

• Allow list to display Mews that fulfill any one of the ParticipationProtocolHerdRules in a list of different ParticipationProtocolHardRules
• Deny list to hide all Mews that fulfill any one of the ParticipationProtocolHerdRules in a list of different ParticipationProtocolHardRules
• Hide flagged content by default (boolean)

Consider replacing node test runner we're currently using 'tape' with another that offers better output for failing tests.

Some options I like:

• ava: https://github.com/avajs/ava
• vitest: https://vitest.dev

$cashtag transaction accounting

• tx grammar
• accounting nodes

This is ported from our prior project management document which was light on the details. My guess is this means that a user can create a mew "send 25 $HOLOFUEL to @jimbo" which will initiate an actual currency transaction from their wallet app.

This is waiting wallets and currencies to exist on holochain

I asked ChatGPT for how to do this.

To integrate a Discord channel with a GitHub repository, you can use a webhook. A webhook is a way for an application to send data to another application in real-time. In this case, GitHub can send notifications to Discord whenever certain events happen in a repository, such as when a new pull request is opened or when a commit is made.

Here are the steps to set up a webhook between GitHub and Discord:

1. In Discord, navigate to the channel you want to receive GitHub notifications in and click on the gear icon to access the server settings.
2. From the server settings, select the "Integrations" tab and click on "Webhooks".
3. Click the "Create Webhook" button and follow the prompts to create a new webhook. You will be asked to give the webhook a name, select the channel it will post to, and customize the webhook's avatar if desired.
4. Once the webhook is created, copy the webhook URL that is generated. You will need to provide this URL to GitHub in order to configure the webhook.
5. In GitHub, navigate to the repository you want to create a webhook for and click on "Settings" in the top navigation bar.
6. From the repository settings, select "Webhooks" from the left-hand menu and click on "Add webhook".
7. Paste the Discord webhook URL you copied earlier into the "Payload URL" field.
8. In the "Content Type" dropdown, select "application/json".
9. Under "Which events would you like to trigger this webhook?", choose the events you want to receive notifications for. For example, if you want to receive notifications when a new pull request is opened, select "Let me select individual events" and then choose "Pull requests" from the list.
10. Click "Add webhook" to save your changes.
11. Now, whenever the events you selected occur in your GitHub repository, a notification will be sent to your Discord channel via the webhook you created. You can customize the webhook settings to control what information is included in the notifications and how they are formatted.

I get stuck at 5. Can't seem to find the settings for the repository and I suspect it's due to missing permissions for me. @mattyg can you look whether you have them there?

Here's the web hook URL: https://discord.com/api/webhooks/1086614464155103333/2GpqP-M5jHDzR_YYc-fcX23IJS0a0xlA7bVMwTMg__GoPiOOHAoCJ0Z2jkHnumvneKff

It occurs to me that twitter and mewsfeed are both deeply individualized architectures, and our Participation Protocols ideas (#62, #63, #64) will only encourage greater individualization and social isolation (i.e I only interact with people I want to in ways I want to).

I would like to imagine possible "bridging" mechanics: ways to facilitate individuals from different social contexts interacting together in co-determined ways that are mutually valuable

Ideas

• counter-signing Mews: multiple agents could create a yarn with participation protocols and inviting others from different social contexts to share this yarn together

Resources

• https://bridging.systems/

Use tailwind (+ daisyui for theming?)

Design: https://www.figma.com/file/GbaNfilKtcB2xBaog6fKzO/MewsFeed?type=design&node-id=0-1&t=wRpShEXe46ttoffl-0

• We will use the sidebar design without labels, just icons
• Search button will open search in a modal
• style list views the same as feed view

Originally by @mattyg , Collab edited by @harlantwood, @dauphin3, @jost-s --

@harlantwood & @dauphin3 are working on integrating TrustGraph 🎉 in #104

Collecting thoughts -- about the initial integration and beyond -- in one place.

Overview

Following

• Instead of "following" an agent being a binary action (either followed or not followed), with trust graphs we can add granularity and context to a follow.
  • Each follow will include: a topic (the type of content that you trust them on) and a trust rating (decimal between between -1.0 and 1.0 of trustworthiness).
• when to exclude mews -- UI should be very clear -- eg a slider like: [Hard Pass]---[Meh]---[Awesome] which mirrors the underlying scale: -1.0 to 0 to 1.0.

Feed

• Split feed UI into 2 tabs -- Chronological (the current feed) and Recommended (TrustGraph powered feed)
• in recommended tab -- needs to be weight and recency combined -- don't want to see very old highly weighted at top
  • could be a simple linear function - eg 2 week window - or window varying per user based on usage patterns
• could have visual tag showing eg ( holochain, 98% ) next to mew to show why I'm seeing it -- ie the properties with which I tagged its author when I followed them
• ideally if I've scrolled one tab and go to the other I don't see mews repeated
• Variable depth of network
  • Display only agents within a trust graph depth of 5 of my trust network (for discovery)
  • Display only agents within a trust graph depth of 3, on the topic of "cooking" (for finding highly trusted chefs and recipes)
  • Display only agents with a trust graph depth > 5 and < 20 (for discovery of agents far outside my trust graph perspective)

Topics

• since we need a concept of "topic" that we trust an agent about, we should incorporate that into the UX. Perhaps by tagging mews with a variety of topics, leaning on #hashtags as topics, or using machine learning to identify commonly used words & phrases
• Display "word could" of topics on a user's profile page. Can we come up with a novel modern UX to bring back word clouds?

Implementation

• In addition to our current "follows", we optionally add TrustAtoms which can be thought of as "nuanced follow information" -- eg ( "cuisine", 99% ).
• On "unfollow", we will delete the relevant TrustAtoms (depends on trustgraph/trustgraph-holochain#67)
• In "Feed - Recommended tab"
  • We query all TrustAtoms created by the Agent
  • We filter for those TAs above a weight threshold (nominally >= 0)
  • We follow those links to get their targets (followed agents)
  • We fetch posts from those agents which mention the relevant hashtags (do we store links for hashtags in DHT currently?)
  • We order these posts according to some combination of: weight of tags and recency
• Other ways we may want to retrieve TAs (TODO add UX use cases)
  • for all of: follow / following / my_followers / my_following zome calls
    • we could add a boolean include_trust_atoms argument
    • we could allow filtering by topic

Clone & extend the concept from twitter of Trending lists.

Overview

• A list is comprised only of Agents, Mews, Replies, Hashtags, Cashtags, or some combination of those types
• Each list is global for the entire DHT
• It is too expensive for every user to generate their own list via a DHT query, thus there will need to be a class of users who act as "indexing" service providers: generating the trending lists which other users simply consume.

A mew author can update the contents of their Mew

Currently the Yarn page only shows responses to that original Mew (i.e. 1 level of depth).

It might be nice if you could not only view those responses, but also the responses to those responses (i.e. > 1 level of depth), all from the same page.

We'll want to think about constraints to the UX (i.e. max levels of depth displayed by default), aiming to avoid a very large unconstrained dht query to fetch all the responses to a very active yarn.