Context

Out of all of the MVP Notification types to be supported, Component Forks are the only event type which is not currently written on-chain.

We need to create a pattern of writing component fork events on-chain and integrate this with the near.org UI (and ideally integrated with tools like bos-cli-rs) such that when a user forks a component and submits the transaction to write the forked component, a payload is included which writes the forked data on-chain.

We can accomplish this by leveraging our socialdbmetrics.near account and write to its socialDB namespace each time a forked component is committed from the near.org gateway.

We need

1. To grant a group of individuals the ability to manage the socialdbmetrics.near namespace in socialDB.
2. These individuals manage the namespace via their ability to grant write permissions onto certain areas within the socialdbmetrics socialDB namespace to the near accounts of individuals representing tools like bos-cli-rs and gateways such as and near.social.
3. A permissionless way to request accommodations from the individuals managing socialdbmetrics.near, e.g. request that a new gateway be granted the ability to write into a socialdbmetrics namespace
4. To restrict write permissions to specific areas within the socialdbmetrics.near socialdb namespace. Such that we can grant alice.near the ability to write into socialdbmetrics.near/post/near.org, while alice.near is denied write access in socialdbmetrics.near/post/bos.gg

Technical approach

The management functionality can be satisfied by two contracts.

1. A namespace-permission-managemment contract, for example deployed at permissions.socialdbmetrics.near, which provides the following api:
2. create_namespace(postNamespace): creates a new namespace at socialdbmetrics.near/post/[postNamespace]
3. grant_write_permissions(publicKey, postNamespace): stores the publicKey into an allowlist of namespaces and the accounts which have the ablity to write to them.
4. set(postNamespace, data): checks the allowlist and returns a permissions error if the publickey associated to the function call is not included in the associated postNamespace map. Otherwise, it writes the data payload into socialdbmetrics.near/post/[postNamespace]
5. bos-cli-rs In order to support collecting fork statistics from any user or automation which leverages bos-cli-rs, bos-cli-rs should be updated to support an explicit fork method, and include metadata indicating that a component has been forked.
6. a sputnikDAOv2 contract deployed at genesis.socialdbmetrics.near. The Dao contact would allow voting and multi-party agreement between the individuals that will manage socialdbmetrics.near (e.g. council members) on for example, who should allowed to write to socialdbmetrics.near namespaces.

{ socialdbmetrics: {
          post: {
            "near.org": 
            {
              "near/widget/NestedDiscussion.Compose": 
              {
                    "forks": 13,
                    "forks_detail": [
                        {
                            "blockHeight": 1234556,
                            "forkedTo": "alice.near/widget/NestedDiscussion.Compose"
                        },
                        {
                            "blockHeight": 871231,
                            "forkedTo": "bob.near/widget/NestedDiscussion.Compose"
                        },
                    ]
                },
              "alphaadmin.near/widget/NearOrg.HomePage": {
                  "forks": 2,
                  "forks_detail": [
                      {
                          "blockHeight": 1234556,
                          "forkedTo": "alice.near/widget/AliceBookStore"
                      },
                      {
                          "blockHeight": 871231,
                          "forkedTo": "bob.near/widget/BobsGarageSale"
                      },
                  ]
                      }
                  }
              }
              "bos-cli-rs": {
               },
                "bos.gg": {
                    ....
                },
                "near.social": {
                    ....
            }
          }
        }
    }

Questions

1. Are socialdB's namespace permissions granular enough to manage permissions for distinct post types? E.g. can we allow a publickey reprsenting 's UI to write to socialdbmetrics.near/post/near.org and not be able to also write to socialdbmetrics.near/post/bos.gg? Or can permission only be managed at the parent 'post' level?
   No, this is not possible on socialDB directly. To accomplish this would require a contract (e.g. permissions.socialdbmetrics.near) which enforces said restriction in an interface to socialDB's set function.

Description

Initial moderation functionality for Discovery

Resources

I've notice that after signing in with my NEAR Wallet this sign in page continues to display.

Just forked repo on Vercel, getting this on first build:

[15:56:55.641] Cloning github.com/Umbrien/bos-gateway (Branch: main, Commit: 25d7af0)
[15:56:55.645] Skipping build cache, deployment was triggered without cache.
[15:56:56.541] Cloning completed: 899.805ms
[15:56:56.730] Running "vercel build"
[15:56:57.205] Vercel CLI 30.2.1
[15:56:57.737] Running "install" command: `npm --force install`...
[15:56:58.046] npm WARN using --force Recommended protections disabled.
[15:57:03.347] npm ERR! code EUNSUPPORTEDPROTOCOL
[15:57:03.348] npm ERR! Unsupported URL Type "workspace:": workspace:*
[15:57:03.349] 
[15:57:03.349] npm ERR! A complete log of this run can be found in:
[15:57:03.349] npm ERR!     /vercel/.npm/_logs/2023-06-08T12_56_58_024Z-debug-0.log
[15:57:03.367] Error: Command "npm --force install" exited with 1
[15:57:03.671] BUILD_UTILS_SPAWN_1: Command "npm --force install" exited with 1```

Is your feature request related to a problem? Please describe.
No ability to onboard via social auth or awallet that has onramp aggregators. Accounts made with ramper wallet not being able to use BOS
Describe the solution you'd like
Integration with ramper wallet https://www.npmjs.com/package/@near-wallet-selector/ramper-wallet (e

Acceptance criteria

• Integrate ramper wallet via wallet selector on near.org/ gateway

Goal
Bring near.social's repost capability to near.org

Test drive the feature on near.social and inspect its components to get an understanding of its mechanics and plan an implementation approach for near.org.

1. Connect a wallet on near.social
2. Click the repost icon on an main page post.
3. magic...

OLD JIRA TASK: https://pagodaplatform.atlassian.net/browse/ROAD-318

Description

This task is for the Designer Team. We would need to update the current flow developed here https://pagodaplatform.atlassian.net/browse/ROAD-309 to encompass new content type other than Account, Comment and Post.

See flowchart and MMP content in https://pagodaplatform.atlassian.net/browse/ROAD-309

Problem
We're received some feedback mentioning being annoyed by having to chase menu options and unexpected UX of click vs hover. @heycorwin this might be worth considering with the new nav designs. We could leverage an approach mentioned in this analysis of an Amazon menu

OLD JIRA TASK: https://pagodaplatform.atlassian.net/browse/ROAD-319

Provide alternative to reporting content to our moderation team by providing the “hide this content“ option at different stage of our reporting journey:

During Reporting Flow (See flowchart https://pagodaplatform.atlassian.net/browse/ROAD-279 ):

At the end of our current Reporting UI and upon confirmation that the report was submitted, we would add additional actions to help users curate their feed. (e.g. “hide this post and all posts from this person” Follow-up: “would you like to hide all posts like this post / from similar posters?”)
Here is some examples below from TikTok and Twitter.

After Moderation Action (See flowchart https://pagodaplatform.atlassian.net/browse/ROAD-279 ):

If the content was ignored by our team, once we notify the user we would also give them the option to hide the content if it hasn’t been done by them already.

The NearCon banner currently has an X icon that hides the banner upon click, but this choice the hide the banner isn't saved, thus the banner reappears whenever a new near.org tab is opened.

Ideal UX
Update the banner such that it saves some state in the client and does not re-appear after someone has chosen to hide it.

Context

Out of all of the MVP Notification types to be supported, Component Forks are the only event type which is not currently written on-chain.

We need to create a pattern of writing component fork events on-chain and integrate this with the near.org UI and tools like bos-cli-rs, such that when a user forks a component and submits the transaction to write the forked component, a payload is included which writes the forked data on-chain.

This can be accomplished by

1. updating each client which initiates the fork to include the following component metadata

{"fork_of": "original/component/path@blockheightAtOriginalComponentLastPublished"}
2. Creating an indexer that parses component metadata and persists a schema that supports

• Showing a count of the number of forks a component has on its component detail page
• Showing links to forked instances of a component on its component detail page
• Sending a notification to the author of the forked component that includes a link to the forked instance and a timestamp of when the fork occurred.

@pkudinov's team can help leverage an existing QueryAPI indexer to support #2
Related Data Platform Issue

Port this PR from near.social to the near.org gateway

**Problem **
How might we enable Flow to be a supported chain on near.org?

Describe the solution you'd like
Must we wait until we have a solid version of WebEngine 2.0? For flow, perhaps it makes sense to do this if we have a specific business need, e.g. someone must create 10 Flow dApps that we can feature (hypothetical).

Describe alternatives you've considered
The ideal would be to announce a timeline on when we'll have webengine 2.0, so Flow developers can prepare to reuse vs rewrite existing applications.

A couple of things should be done in this repo order to better support moving to NextJS and Typescript.

1. Unfork this repo because it won't be merged up into the original project anymore
   • Update the readme to include a contributing section that describes the gitflow in simple terms - see the same section from near-discovery-widgets
   • Update the settings on the repo to ensure main branch is protected from direct pushing and require at least 1 approval on PRs
   • Set the develop branch as the default branch
2. Move to NextJS v13 and Typescript
   We can start by renaming files to .ts and .tsx

FastAuth does not work for me. Can someone fix it asap? (I have a talk today, a hackathon tomorrow, and next week it will be EthCC) (edited)

Currently, the component we use for managing versions of TOS files is adminalpha.near/widget/TosContent. Due to the way the acceptance check is built in near/widget/TosCheck, we cannot switch the content component without triggering a new prompt for acceptance for all users across the board. The next time we make a change to one of the TOS docs(or add a new one) we should update the TosContent component on the near account and switch to using that. The following line can be updated to make that switch once the new component is ready

Description

Give ability to flag any other content type than Account, Post and Comment

Detail

Provide ability for user to “Flag“ Components, Groups (if existing) and Chat (if existing) for moderation no matter where the object is displayed on the platform (e.g. feed, search etc…).

Flagging the object should enqueue the content into our current moderation queue (https://near.org/mob.near/widget/Flagged.Feed)

Similar to when reporting posts or comments we should also display a confirmation message to users that the content has being flagged and will be reviewed.

When flagging a post or comment we usually hide the content from the reporter’s view. Once the reporter report an object, offer them the possibility to also hide the object so that they can’t interact with it anymore.

OLD JIRA TASK: https://pagodaplatform.atlassian.net/browse/ROAD-324

Description

When content has been hidden after a community decision we will give the option for content creator to appeal that decision once.

User Experience

The option will be accessible via:

The report UI (#398)

The Notification page https://near.org/near/widget/NotificationsPage

Once accessed, the user will have the ability to fill out a form describing why they believe we should review our decision. The form will re-send the content in the queue for another round of content review. The final decision will be then shared with the user and they will not be able to appeal it afterwards.

Design

The appeal flow will simply be a form at a first stage

1. Please add a permanent redirection of requests from learn.near.org to wiki.near.org/support/learning

Old Jira link: https://pagodaplatform.atlassian.net/browse/ROAD-309

This feature request is meant to finalize how the entire the reporting UI should be displayed to users for reporting Comment, Posts and Accounts.
Here is a competitive analysis: https://pagodaplatform.atlassian.net/wiki/spaces/SITS/pages/295927815/Competitor+Analysis+for+Content+Reporting+UI

Here are the details we need to agree on:

How users should navigate between content they don’t consider violating but might be undesirable. Display a flow that is clear, concise and lead to clear actions (Display additional options such as Block Creator, Filter Out Specific Topic, and any relevant Customized Content Preferences features.).

When the user consider the content to be violating, what additional information would we require from them.

Clarify whether would we need a different flow for each content type and what they would look like in details.

Clarify how we would want users (content reporter and creator) to be notified.

Problem

UI performance of near.org does not match a typical user's expectations, and is extremely poor with an internet speed below 200 Mbps.

Areas for Improvement

• Improve performance when running near.org locally via pnpm dev
• Improve the fetching of components from the VM. Currently, each URL update refreshes the entire UI (must each URL update re-fetch VM component?)
• Improve the Caching of Data fetched by VM components

How might we improve UI performance for each of the above areas?

Relevant Conversations

• Considering Redux w/ Flux architecture tl; dr; We could expand our use of Zustand to accomplish the same as redux, however this would not address the source of our rendering bottleneck: loading components from the VM & component data fetching.
• Porting more components to QueryAPI

Our product analytics options supports enabling a cookie management screen when rudderstack is initialized. As part of this ticket, cookie consent manage should be enabled and our collection of usage analytics should honor the options that a user may choose with respect to data collection.

Replace the highlighted/quoted text in whichever of the these phrases is more appropriate

1. https://sso.teachable.com/secure/1354850/identity/login/password routes to wiki.near.org/support/learning. Can we restore its original redirect to the Teachable dashboard after user logs in?

The performance of more complex pages like the Activity Page can be fairly poor (slow load time, interaction lag) depending on your connection quality and device. When running the gateway locally, the performance issues are far worse - even on high end connections and modern devices.

Is this an issue with the VM? Or with how we're initializing and utilizing the VM within our Next JS application? It's a tough question, but worth digging into.

OLD JIRA TASK: https://pagodaplatform.atlassian.net/browse/ROAD-320

Description

Give users the ability to highlight exactly what they consider to be violating when they report certain content so that it helps moderators narrow down where the issue might be.

User Experience

User flags a post who they deem to go against our Community Guidelines via the Flag button.

Once they do that, they will mark the content as violating and decide to provide additional context by click on the “Highlight violating section“ option.

Following this, they will see the post again and will have the ability to specifically highlight the text they believe to be violating.

Finally, they will confirm their report and send the content for moderation.

Design and Message

We would surface this option wherever the content is being reported and contain some text that can be highlighted. The highlight will look like the below screenshot.

The text following the action could be:

Call for highlight: “Please highlight the text you believe to be violative so that it can help our Community assess the content”

Build the UI + Supporting backend components to support pathways into a Content Moderation flow from Settings, Profile, and the Activity feed as detailed in these designs

The facet on the page should be shaded in, in my opinion, to show the current page selected.

For example in the image here I'm on the view source page but the facet does not reflect that as it's the same color as the other facets

For existing users, we want to show the Enable Push Notification modal that is prepared in this PR

There is also a question, when we want to show the Enable Push Notification modal, under what conditions.

Is there a way to add a short url for the public profile widget?

https://alpha.near.org/#/sainthiago.near would redirect to https://alpha.near.org/#/adminalpha.near/widget/ProfilePage?accountId=sainthiago.near

When using the bos-loader, on a full page reload I get some VM is dead errors for certain components for a brief moment. The first time I launched it (before being logged in, but after setting the flags for the bos-loader) all components showed this behavior.

Problem
The Here wallet exists as a downloadable mobile app. Here does not currently have a web client wallet. Therefore, when near.org offers desktop users the option to connect via here wallet, users are unable to complete this flow because a web login option does not exists for Here wallet users.

To Reproduce
Steps to reproduce the behavior:

1. Go to near.org from a desktop browser
2. Click on Sign In -> Continue with Wallet
3. Choose Here
4. Try to complete the sign in flow

Expected behavior
We should only offer Here wallet as an option in wallet selector if users are on a mobile device

Describe the bug:
When forking an existing component and making changes to source code the changes do not persist in local storage.

To Reproduce:
Steps to reproduce the behavior:

1. Go to near.org and fork any existing component
2. Make changes to the source code
3. Hit the "back" button on your browser
4. Hit "forward" button on your browser
5. See changes deleted

Expected behavior:
Step 5 should have changes still present.

Additional context:
This issue does not present itself when creating a "new" component.

OLD JIRA TASK: https://pagodaplatform.atlassian.net/browse/ROAD-279

Description

As content reporter: Create a specific UI meant to view current and past moderation report with their status. It will also provide the user with additional actions like blocking content creator from reports.

As content creator: Leverage the same UI mentioned above only adding also the content owned by the content creator that have been hidden by our community and enable the option to appeal once.

User Experience

The UI will be accessible in 2 ways:

Via the notification page https://near.org/#/near/widget/NotificationsPage directly next to the content report.

Via a tab located in the Profile page (need to be clarified)

Once accessed, the UI will contain the following information:

Present and past report with links to content and status

Potential follow up action depending on report status (see https://pagodaplatform.atlassian.net/browse/ROAD-313 for more details)

Ability to appeal report when applicable

Currently we have return command in the top-level of the code for valid component. In my opinion if we have fully-compatible component just like in javascript, it would be better because I can have the same tooling e.g. ESLint.

Before

let greeting = "Have a great day";

return (
  <>
    <div class="container border border-info p-3 text-center min-vw-100">
      <h1>Hologram AI</h1>
      <p>What you are imagining today?</p>
    </div>
  </>
);

After

let greeting = "Have a great day";

const main = () => {
  return (
    <>
      <div class="container border border-info p-3 text-center min-vw-100">
        <h1>Hologram AI</h1>
        <p>What you are imagining today?</p>
      </div>
    </>
  );
}

For new users, that just finished the Create Account process, we want to show the Enable Push Notification modal that is prepared in this PR

Describe the bug
Since August 31st there's been a roughly 94% drop in the product analytics data transmitted from near.org. This corresponds with the date and merge of this PR.

To Reproduce
Steps to reproduce the behavior:

1. View ingested events for prod on rudderstack
2. Filter by the past 30 days

Expected behavior
If this drop is expected, then there must have been an error in our previous implemented that caused excess events to be sent. If this is unexpected, we should be able to find the root cause.

Describe the bug
When content is flagged, there is a long delay before the UI responds. Leading to a perception that an error has occurred.

Expected behavior
Perceived performance can be improved if the UI was optimistic, assuming success by immediately showing the toast. The flagged content can be removed once the transaction is successfully processed. If an error occurs, and error message could be displayed even if a success message was initially shown.

When forking a component from the Component Details page or from the Develop top-nav menu item, the Onboarding flow screen flashes temporarily. Sometimes the screen stays and the forked component never appears.

To Reproduce
Steps to reproduce the behavior:

1. Go to near.org
2. Click on View Details for any featured component
3. Click Fork
4. The flash screen should appear

Expected behavior
The IDE should appear with the code of forked component

Screenshots

Desktop (please complete the following information):

• Chrome v114.0

near.org's Developer Office Hours page is out of date! Please update pages.near.org/developers/get-help/office-hours with these lines referencing the page's main content:

Developer Office Hours

Ask your questions about developing dApps on NEAR or decentralized front-ends on BOS!
Or just come hang out with us and learn what others are up to.

Americas
Thursdays
18:00 – 19:00 UTC (11AM-12PM PST)

+ Add to Calendar

Europe/Africa/Asia
Thursdays
11:00 – 12:00 UTC (1PM-2PM CEST)

+ Add to Calendar

And add below:

Other Ecosystem Office Hours

• BuildDAO (Banyan) BOS Office Hours: (Daily) 15:00-16:00 UTC (with DevHub on Wednesdays)

  BOS Office Hours

• NEAR Horizon: Fridays at 17:00 UTC (10AM PST)

  Horizon Office Hours

• Chinese NEAR Developer Office Hours (Lit Tech): 12:00 UTC (20:00 CST)

  NEAR China Office Hours

• NEAR Korea Hub Developer Lounge (Discord)

  NEAR Korea Dev Lounge

And update the content in the column container below that:

Hopefully this copy-pastes into a WordPress editor reasonably well, I wanted to minimize any further work (I edited the site by downloading the HTML, which I now realize might not be 1:1).

Thanks!

I have the following components:

const getRandomInt = (max) => {
  return Math.floor(Math.random() * max);
}
const getPrompt = (page, cb) => asyncFetch(`https://alpha.tryhologram.art/api/prompt/pagination?page=${page}`).then(cb);

const initialPage = getRandomInt(100);
const lastPage = initialPage + 10;


State.init({
  contents: [],
  currentPage: initialPage,
  lastPage: lastPage
});


const loadMore = () => {
  const newPage = state.currentPage + 1;
  getPrompt(newPage, (res) => {
+     console.log({res});
    State.update({
      contents: state.contents.concat(res.body.prompt.rows),
      currentPage: newPage,
      lastPage: res.body.lastPage,
    });
  });
}


return (
  <>
    <div class="container border border-info p-3 text-center min-vw-100">
      <h1>Hologram AI</h1>
      <p>What you are imagining today?</p>
    </div>
    <div className="px-2 mx-auto" >
      <InfiniteScroll
        loadMore={loadMore}
        hasMore={state.currentPage ? state.currentPage < state.lastPage : true} // infinite
      >
        {state.contents.map(c => <img src={c.imageUrl}/>)}
      </InfiniteScroll>
    </div>
  </>
);

Without the console.log it wouldn't refresh the component. But with the console.log it refresh the component. You can try by running above code.

Found during Encode x NEAR Aurora hackathon.

Is your feature request related to a problem? Please describe.
This task is meant to agree on the Setting page we have discussed here and think about the different tabs we will be needed as a first version (e.g. Notifications, News Feed, Account Preferences...)

Describe the solution you'd like
Creation of Setting page with Identity information included and Notification.
We would also need to think about what to include in the other tabs and whether these informations are available at the moment (e.g. News Feed would lead to settings enabling users to control what they would see but we don't have that feature at the moment.) However, we do have Notifications settings and will have GDPR related features like exporting of data.

Describe alternatives you've considered
Start with very light MVP with what we have (1 or 2 tabs: "Identity and Data Privacy" & Notifications) and continue to use this task to add all of the other tabs as the product become available (e.g. GDPR related features).

Additional context

Currently, fast auth runs within near discovery and webauthn keys are stored within that scope. Fast auth needs to be separated from near discovery to support signing with FAKs so that BOS components can redirect to a signer app and the user can be prompted for their webauthn FAK in a secure domain instead of arbitrarily prompted on the same domain which could lead to phishing.

Is your feature request related to a problem? Please describe.
User verification by third parties or social graph provides an important signal about posts on Discovery. Currently unique human verification is available. Surface this information.

Proposed Solution
In the post view (in feeds and standalone), in the author component show a 'verified human' badge for authors who have completed i-am-human verification.

Task list

• Write indexer of i-am-human contract.
• Fetch data in feed
• Display in component
• Implement badge design
• Implement mousover design
• Move indexer to dataplatform account
• Change inline fetch to join
• Finalize design

Old Jira Task: https://pagodaplatform.atlassian.net/browse/ROAD-279

Description

Summary: Creating a reporting flow for http://near.org/ , including designing a user interface for tracking reported content, implementing notification systems for users regarding moderator decisions, adding a pop-up confirmation message when content is reported, and considering the inclusion of optional violation options for users when reporting.

Resources

Product Hypothesis: https://docs.google.com/document/d/1rs1LZld_eZ2_YaCPvH9x8kWrzLxSjDtJJzd2UpzIC-w/edit#heading=h.cvd6d15qyce

Figma Ideation Session: https://www.figma.com/file/2DLXKTN9kH0zwDQpr1CvHs/Ideation%3A-Reporting?type=whiteboard&node-id=68-233&t=NSoIHbmH9vCK4aRI-0

For some reason I can't fork ProfileEditor widget.

Maybe this bug relates not to only this widget.

Here is loom video: https://www.loom.com/share/db14f28b226d4a54801f6f3b2ae36e9d
More context here: https://pagodaplatform.slack.com/archives/C04QKBVV7DF/p1678808887723779

Old Jira Link: https://pagodaplatform.atlassian.net/browse/ROAD-307

Provide ability for user to “Flag“ an account for moderation no matter where the account is displayed on the platform (e.g. feed, directly on someone’s profile etc…).

Flagging the account should enqueue the content into our current moderation queue (https://near.org/mob.near/widget/Flagged.Feed)

Similar to when reporting posts or comments we should also display a confirmation message to users that the content has being flagged and will be reviewed.

When flagging a post or comment we usually hide the content from the reporter’s view. Once the reporter report an account, offer them the possibility to also hide the account from their feed if they wish to.