Foundation Mission Request - Farcaster Attestations [IDENTITY]

Proposed Foundation Mission Request: Enable easy interoperation between Farcaster accounts and Ethereum Attestation Service, such that Farcaster accounts can effectively ‘issue’ attestations.
S5 Intent: Improve governance accessibility
Proposal Tier Ember
Baseline grant amount: 10k OP per solution for up to 2 solutions
Should this Foundation Mission be fulfilled by one or multiple teams: Up to two teams
**OP Labs or Optimism Foundation Sponsor: @C-Emily-Furlong *
Submit by: June 15th 2024
Selection by: June 30th 2024
Start date: June 30th 2024
Completion date: by August 30th 2024

How will this Foundation Mission Request help accomplish the above Intent?
This Mission Request calls for critical infrastructure enabling better compatibility between EAS Attestations and Farcaster accounts. Attestations are a critical piece of governance infrastructure and a core primitive of the OP Stack and will continue to remain a key building block of reputation within the Collective.
This Mission will enable the Collective to leverage Farcaster to improve governance accessibility while maintaining attestation compatibility and composability.
What is required to execute this Foundation Mission Request?
Problem statement
We want Farcaster accounts to more effectively and efficiently ‘issue’ attestations. Farcaster accounts have several connected Ethereum addresses. [Custody and recovery addresses](https://docs.farcaster.xyz/reference/contracts/reference/id-registry) are verifiable on-chain via the Id registry contracts and so-called ‘[verified addresses’ are only verifiable off-chain](https://docs.farcaster.xyz/reference/hubble/httpapi/verification). These address mappings can be changed over time by the user.
The holder of a Farcaster account may issue an attestation from one of the Ethereum addresses connected to their account, but for third parties to be sure that an attestation was issued by the person behind a Farcaster account, the Ethereum address must be connected to that account at the point in time that the attestation was issued. This connection must be verifiable on-chain for resolver contracts to be able to enforce it in the process of issuing attestations. Only custody and recovery addresses are verifiable on-chain, but users rarely have access to them to sign messages like attestations.
Use case
In the [Retroactive Public Goods Funding (Retro Funding) Round 4 sign-up experience](https://retrofunding.optimism.io/), users sign in with their Farcaster accounts, create projects and apply for Retro Funding. Projects are represented onchain as attestations, with the attestation UID acting as the project identifier to be used across future Retro Funding Rounds and Grant applications. The project attestation schema contains a ‘created by’ field, which references the Farcaster account id of the user who created the project.
Currently the attestation is issued by the sign-up app and attestation consumers must trust that the app correctly identified the user by their Farcaster id. The desired outcome is that users themselves are able to issue this project attestation, as well as other attestations about their projects, and third parties can read those attestations and trust that the project was indeed created by the holder of the Farcaster account. Third parties can further reference these attestations to add context to the impact of these projects and much more.
Suggested avenues to explore
In our exploration of this problem space, we have come across two ideas for solution avenues, which we think offer different trade-offs and would both be valuable additions to the EAS <> Farcaster tool set. It is up to the teams applying for this Mission to assess the viability of these ideas and suggest an appropriate technical architecture in their application. Alternative ideas for how to solve this problem are welcome.
Teams can apply to build one or multiple solutions, including suggesting solution ideas that are not listed below. The OP reward will be adjusted depending on the scope of the solution(s) proposed by teams.
Avenue 1

Attestations are issued by user action via their Ethereum account (EOA/smart account)
The Ethereum address is onchain verifiably associated with the user’s Farcaster account via a new onchain registry mapping Farcaster accounts to Ethereum accounts used for issuing attestations
This Ethereum address <> Farcaster relationship can be checked via a [resolver contract](https://docs.attest.org/docs/core--concepts/resolver-contracts).
The resolver contract enforces that the issuer’s Farcaster id is correctly entered into the attestation schema.

Solution requirements avenue 1

There is an easy way for Farcaster users to register an Ethereum address that they want to use for issuing attestations on behalf of their Farcaster account.

It is easy for developers to integrate this step into their application, in case they want a user to issue an attestation but the user has not yet done this registration.

Anyone can create an attestation schema that enforces the following rules:

Only those with a Farcaster account can issue attestations from this schema.
Their Farcaster account id is correctly entered into the attestation metadata when they issue it (enforced via resolver contract)

Anyone consuming these kinds of attestations is able to trust that the Farcaster id given in the attestation metadata is the effective issuer of the attestation.

Avenue 2

Attestations are issued on behalf of a Farcaster user by an application that has an account key for the Farcaster user
The application issues the attestation, using the account key to generate a signature, which is included in the attestation metadata along with the Farcaster id of the user
The attestation schema includes a [resolver contract](https://docs.attest.org/docs/core--concepts/resolver-contracts) that is able to enforce that the signature corresponds to an account key registered to the Farcaster account included in the attestation metadata
Attestation consumers are able to verify whether the account key used to issue the attestation is still valid, or if it was revoked by the user

Solution requirements avenue 2

Any application with an account key for a Farcaster user can issue attestations on behalf of the user
They can use a schema with a new resolver contract to prove that they held an account key for the user at the time the attestation was issued
The Farcaster.id of the user is included in the attestation metadata so attestation consumers know on whose behalf the attestation was issued
Third parties consuming the attestations can trust that the attestations were issued by an application that (at the time of issuance) had an account key for the Farcaster user specified in the attestation metadata.

They can also easily verify whether that account key is still valid

Definition of done

Anyone is permissionlessly able to create an EAS attestation schema that includes Farcaster id as a required field designed to represent the effective issuer of the attestation
Consumers of attestations from this schema can trust that the Farcaster id in the attestation effectively ‘issued’ the attestation, via either of these options:

The application that issued the attestation had an account key for the Farcaster user
The Ethereum account of the issuer was associated with the Farcaster account at the time of issuance

Provide a list of example schema UIDs being used that successfully create an attestation with a verifiable Farcaster id associated with it.

How should the Foundation measure progress toward this Mission Request?

Develop a plan and document it as an architecture diagram to be shared with the sponsor for feedback (1 week)
Develop a prototype / testable solution (2 weeks)
Release a production-grade solution that complies with the definition of done and applicable solution requirements above (4 weeks)

How should badgeholders measure impact upon completion of this Mission (RFP)?

Number of attestation schemas created with the requirements described above
Number of attestations issued with the requirements described above

Application instructions
To apply for this RFP, please complete the form in the expandable section below and leave your response as a comment on this issue thread. Submissions will be open until June 15, at which time the Foundation will review all submissions and select one or two individuals/teams to complete the work defined here.

Submission form
Copy the entire application below and leave a comment on this issue with your answers completed. A representative from the Optimism Foundation may reach out using the contact info provided to request more information as necessary.
Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier

Alliance Lead: Please specify the best point of contact for your team
Contact info:
L2 recipient address:
Please list the members of your Alliance and link to any previous work:

Read more about Alliances here

What makes your Alliance best-suited to execute this Mission?

[...]
[...]

Please describe your proposed solution based on the above Solution Criteria (if applicable):

[...]
[...]

Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:

[...]
[...]

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

[...]
[...]

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

[...]
[...]

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

[...]

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[ ] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[ ] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[ ] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[ ] I confirm that I have read and understand the grant policies
[ ] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Bravo farcaster

👀

Github connect farcaster

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier
RetroList has received 49k OP in RetroPGF 3

Alliance Lead: Chomtana Chanjaraswichai
Contact info<EMAIL_ADDRESS>L2 recipient address:
Please list the members of your Alliance and link to any previous work:

Read more about Alliances here

What makes your Alliance best-suited to execute this Mission?**
We have built RetroList, the first and only Retro Funding 4 Discovery UI available so far. Our platform queries and indexes project data directly from the EAS, while others are still waiting for the Agora API to integrate real data. This showcases our expertise in EAS Attestation.
Moreover, we have years of experience in the identity field, demonstrated through the development of Opti.Domains, which integrates social verification with EAS attestation. To date, we have completed over 10,000 attestations related to social and wallet verification linked to domains.
In the domain attestation, we use namehash as the primary identifier, similar to how Farcaster uses Farcaster ID for attestations. We have experience with this non-address-centric attestation system.
Furthermore, as a leading team developing Retro Funding discovery and community voting UI, we already have a high level of understanding of how this Farcaster attestation system can be used. This expertise enables us to cooperate more effectively with the Agora and Gitcoin teams.
Please describe your proposed solution based on the above Solution Criteria (if applicable):**
We are looking to develop Avenue 1 solution
Attesting offchain farcaster wallet verification onchain
We will implement a system that queries off-chain wallet verification from the Hubble API and attests it on-chain through EAS with a resolver that automatically saves and indexes the Farcaster wallet verification status. This enables other contracts, applications, and resolvers to query this data to check if a Farcaster wallet has been verified.
Thanks to the OP Fjord upgrade, which implements "RIP-7212: Precompile for secp256r1 Curve Support," we can verify the Farcaster ED25519 signature on-chain.
We will provide an SDK and Wagmi hook for third-party applications to implement Farcaster attestation. This allows applications to check for wallet verification status and handle wallet verification attestation, so developers do not need to understand the underlying logic and can implement it easily.
The user experience will be similar to token approval, where the user needs to approve the Farcaster <-> wallet connection once globally. After this, the user can perform Farcaster attestations via the approved wallet without requiring further permissions.
Attesting Farcaster Attestation
We will provide core contracts with examples for smart contract developers to easily develop and integrate Farcaster attestation resolvers. These resolvers will verify the Farcaster wallet connection before allowing the attestation to proceed.
Simple attestations that follow our recommended attestation standard can simply set our pre-deployed resolver as the default resolver while creating a schema.
Our SDK allows developers to build Farcaster attestation data with just a few lines of code. Additionally, it supports a Wagmi hook that enables developers to perform attestations with Farcaster in a streamlined manner.
We will also support or collaborate with Agora, Gitcoin, RetroList, and any team working on Farcaster attestations for Retro Funding use cases.
Recommended Attestation Standard
We recommend the following standard for Farcaster attestations to make them more useful and better organized.
Farcaster Recipient Namespace
Currently, the Retro Funding application attestation is not attested to a recipient. This prevents standard attestation indexers from efficiently indexing the attestation. For example, we can't easily query the EAS GraphQL API to find every project attested by @optidomains. Moreover, integration with guild.xyz is more difficult.
To address this, we introduce the address 0xfa...<Farcaster ID in hex> as a representative of the Farcaster account to be used as the recipient.
However, this is optional, and application developers can choose not to follow it if needed.
Farcaster ID as the First Field
The Farcaster ID should be the first field for seamless integration with our Farcaster attestation resolver SDK and for optimal indexing. However, if the Farcaster ID cannot be the first field, developers can manually decode the Farcaster ID and pass it to our Farcaster attestation resolver SDK during resolver development.
Developer Support Channel
We will host a developer support channel similar to the "Optimism Agora API beta" channel.
We will provide technical resources to TechNerd for answering Farcaster attestation-related questions on the developer forum and Discord. As a fellow TechNerd, I can easily coordinate with the rest of the TechNerd team.
Guild.xyz Support
We will coordinate and collaborate with Guild.xyz to implement support for Farcaster attestation. However, we can't guarantee success in this effort, and it is not a critical requirement, so we don't include it in the critical milestones.
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each peice of work:**

Develop on-chain Farcaster wallet verification resolver - 14 July
Develop Farcaster attestation resolver core contracts and examples - 21 July
Develop Farcaster attestation SDK and Wagmi integration - 28 July
Conduct internal testing - 4 August
Support critical teams in integrating Farcaster attestation and fixing bugs - From 4 August onward

Critical teams are those that work on missions dependent on Farcaster attestation, including but not limited to the Retro Funding application and the voting UI development team.
Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:**

The Farcaster wallet verification resolver is deployed and functioning
The Farcaster attestation resolver is developed
The Farcaster attestation SDK is developed
The critical teams have successfully integrated Farcaster attestation

Please list any additional support your team would require to execute this mission (financial, technical, etc.):**

Coordination with the OP Foundation
Coordination with the Farcaster and Warpcast teams
Coordination with the EAS team
Coordination with critical teams

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant:** (Note: there is no guarantee that approved Missions will receive up-front cash grants.)
Not a problem

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above Tier

Alliance Lead: LukeMa
Contact info:

Email<EMAIL_ADDRESS>Github: lukema95
L2 recipient address: 0x64637e33fb29fe6fdaf3e78515c805617ddc6188

Please list the members of your Alliance and link to any previous work:

LukeMa: Experienced blockchain engineer, who has contributed code to several blockchain open source projects including Cosmos-SDK, IBC, ZetaChain, etc., here are some of his most recent open source projects:

zetachain/node
zetachain/toolkit
zetachain/example-contracts

zhouop0: Experienced full stack engineer with 10+ years of web2 experience and several years of web3 experience

What makes your Alliance best-suited to execute this Mission?

Extensive Expertise in Web3 Development: Our alliance boasts over three years of comprehensive experience in the Web3 sector, encompassing a broad spectrum of essential skills such as frontend and backend development, smart contract creation, and public blockchain development. This diverse skill set ensures that we are equipped to handle complex challenges across all layers of blockchain technology
Proven Track Record in Blockchain Innovation: We have actively contributed to the advancement of major blockchain ecosystems, including Sui, Cosmos, Ethereum, and ZetaChain. Our involvement has not only propelled these projects forward but also given us unique insights and a robust understanding of various blockchain architectures and consensus mechanisms.
Dedicated Involvement with Farcaster and Optimism: Our enthusiasm for innovative platforms like Farcaster and Optimism has led us to invest significant effort in understanding and contributing to these networks. Our proactive engagement demonstrates our commitment to supporting and enhancing these ecosystems, aligning perfectly with the mission’s goals.

Please describe your proposed solution based on the above Solution Criteria (if applicable):
We are looking to develop [Solution requirement avenue 2] which encompasses two key processes:

Farcaster User Registration Key - When Farcaster users link their application, the application generates a public-private key pair. The private key is stored on the application side, and the application utilizes Wrapcast's Signer Request API to add the program-generated key for the user.
Issuing Attestation for Farcaster Users - The application uses the private key generated in the previous step to sign the proof request data, then calls the EAS contract to issue the attestation for the user.

Key Components
Farcaster Login UI Component
We will develop a UI component for applications to log in to Farcaster accounts, which will be integrated into ReactJS and NextJS. This integration will allow applications to swiftly incorporate it into their frontend interfaces.
Farcaster/EAS Interaction SDK
We will develop a comprehensive TypeScript SDK for both frontend and backend use, which will later be expanded to other languages like Go and Rust. Its primary functionalities include registering application-side keys for Farcaster users, interacting with the EAS contract to issue proofs, creating schemas, and verifying users' proofs.
Schema Template Contract
We plan to develop a set of schema templates and instances suitable for issuing Farcaster proofs. The schema must contain the Farcaster user's fid and essential fields like the Farcaster account's Key. Here is an example:
// Retro Funding 4
schema {
	fid: uint256 // farcaster id
	key: string // key
	project_name: string
	project_url: string
	parent_project_ref_uid: uint256
}

Resolver Verification Contract
The Resolver contract is used to verify the validity of the attestation, ensuring they are authorized by legitimate Farcaster accounts. Since the attestation has already been verified as signed by a specific Farcaster account key, the Resolver only needs to confirm that this key matches the existing Farcaster account. Below is an implementation example.
contract ForcasterResolver is SchemaResolver {
    // ...
    KeyRegistry keyRegistry; // farcaster keyRegistry
    function onAttest(Attestation calldata attestation, uint256 value) internal view override returns (bool) {
        // decode fid from data
        (uint256 _fid, bytes key) = abi.decode(attestation.data, （uint256, bytes）);
        uint256 fid = keyRegister.keyDataOf(_fid, key);
        require(fid == _fid, "Does not match fid");
    }
}

Comprehensive Developer Documentation
We will provide complete developer documentation and examples to enable developers to quickly integrate the attestation system into their applications.
Week 1: Preparation (30/06/2024 - 06/07/2024)

Design and discuss specific plans, and determine the final plan

Weeks 2 - 5:  Code development (07/07/2024 - 03/08/2024)

Development of the Farcaster frontend login component.
Development of the TypeScript SDK.
Development and deployment of core modules like Schema and Resolver contracts.

Weeks 6 - 7: Test & Docs (04/08/2024 - 10/08/2024)

Conduct extensive testing, including smart contracts, SDKs, and frontend UI components.
Compilation of developer documentation.

Week 8: Acceptance and feedback (11/08/2024 - 17/08/2024)

Gather feedback from key teams and the community, organize it, and make necessary improvements.

Please define the critical milestone(s) that should be used to determine whether you’ve executed on this proposal:

Completion of the Farcaster UI frontend login component development.
Completion of the TypeScript SDK for interaction with Farcaster/EAS.
Development and deployment of the Schema template example contract.
Development and deployment of the Resolver verification contract.
Completion of the development of developer documentation.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Coordination with the OP Foundation

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)
Not required
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x]  I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x]  I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x]  I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types)
[x]  I confirm that I have read and understand the [grant policies](https://gov.optimism.io/t/token-house-grant-policies/5833)
[x]  I understand that I will be expected to following the public grant reporting requirements outlined [here](https://gov.optimism.io/t/suggested-public-reporting-requirements-for-grantees/4176)

-- end of application --

Foundation Mission (RFP) Application
Please verify that you meet the qualifications for submitting at the above [Tier](https://gov.optimism.io/t/collective-trust-tiers/5877/2)

Alliance Lead: Alexander Balandin
Contact info<EMAIL_ADDRESS>L2 recipient address: 0x76ef7734E8c5f84b62e3b8fAae6F4995bFea64AB
Please list the members of your Alliance and link to any previous work:

Marwan Aziz - Core engineer with 30+ years of web2 experience and several years of web3 experience:

Was a member of a team that won the Truflation prize in the Chainlink Hackathon of 2022 - here is the link: https://devpost.com/software/fortunity
Worked on the following two projects as part of the Chainlink 2021 hackathon: https://salientyachts.com/
Worked on the NFT and reward token contracts: https://www.versafy.co/
Worked on the DAO factory contract

Alexander Balandin - Full-Stack Engineer, ex Microsoft engineer with 7 years experience in IT and 2 years in Web3 development:

https://github.com/Rainbow1nTheDark/Optimist
https://github.com/Rainbow1nTheDark/Onyx-SDK

Read more about Alliances [here](https://gov.optimism.io/t/season-4-alliance-guide/5873)

What makes your Alliance best-suited to execute this Mission?
Our team possesses extensive experience both as creators and consumers in the Web3 space. Our mission is to make Web3 more accessible and user-friendly for newcomers. We believe that enhancing the infrastructure for better compatibility between EAS Attestations and Farcaster accounts will significantly open the protocol for further development, fostering innovation on top of our solution.
As part of our expertise, we have worked extensively with EAS. For our final project in the Expert Solidity course, we built a decentralized application (Dapp) designed for users to rate and review other decentralized applications - Optimist. This project aimed to foster a community-driven reputation system, helping users make informed decisions about which Dapps to trust and use.
We are inspired by Chris Dixon's vision for decentralized social applications and have a deep understanding of Farcaster's mission and we are eager to contribute to its success.
Additionally, we are senior software developers with extensive experience in architecture and development. We believe our skills and dedication make us well-suited to contribute to this project and advance the Web3 ecosystem.
Please describe your proposed solution based on the above Solution Criteria (if applicable):
We are looking to develop Avenue 2 solution
Solution Proposal
Our solution involves building an application through which users interact with Farcaster contracts. The following outlines our approach:
User Interaction and Authentication

User Requirements: Users must have a valid Farcaster ID (fid) and a blockchain account. They will need to connect their wallet when interacting with the Farcaster contracts.
Authentication: Users authenticate with the application using Farcaster authentication mechanisms.

Fetching Farcaster ID

FID Retrieval: Once authenticated, we retrieve the user's Farcaster ID (fid) using their Farcaster username.

Account Key Management

Creating and Revoking Account Keys: Users can create and revoke Farcaster Account keys through the application.

Key Creation: We use the Farcaster "Key Gateway" contract to add new keys.
Key Removal: We use the Farcaster "Key Registry" contract to remove keys. The same contract will also be used to query the keys of a Farcaster ID.

Attestation Process

Key Requirements: Creating a Farcaster Account key requires the user's authentication and a valid Farcaster ID.
Attestation Schema Requirements: The schema for attestations must include:

Farcaster ID (fid)
Farcaster Account key

Resolver Contract: The schema will be linked to a resolver contract that:

Verifies the Farcaster Account key belongs to the provided Farcaster ID.
Confirms the key status is "Added".
Blocks attestation if the conditions are not met.

Verification by Third Parties

Attestation Record: By storing the Farcaster ID and Farcaster Account key in the attestation record, third parties can verify:

Ownership of the Farcaster ID (and, by extension, the username).
Validity of the key used at the time of attestation creation.

This approach ensures secure and verifiable attestations, enhancing trust and usability within the Farcaster ecosystem.
Please outline your step-by-step plan to execute this Mission, including expected deadlines to complete each piece of work:
Step 1: Preparation (2024-06-30 - 2024-07-05)

Design and Planning: Finalize specific plans and design the system architecture. Determine resource allocation and timeline.

Step 2: Development (2024-07-06 - 2024-07-31)

Develop the Resolver Contract
Develop Sample Schemas that can be used for the Attestations.

Step 3: Testing and Documentation (2024-08-01 - 2024-08-31)

Internal Testing:

Conduct extensive testing of the resolver contracts and SDK.
Address any bugs or issues found during testing to ensure reliability.

Developer Documentation:

Compile comprehensive documentation for developers.
Include examples, API references, and integration guides.

Step 4: Support (Starting 2024-09-01 and Ongoing)

Community and Developer Support:

Set up support channels on Discord and Twitter.
Provide ongoing support and updates to critical teams.
Gather feedback from the community and incorporate improvements.

Please define the [critical milestone(s)](https://gov.optimism.io/t/grant-policies/5833) that should be used to determine whether you’ve executed on this proposal:

Deployment and Functionality of Farcaster Wallet Verification Resolver:

Ensure the resolver is live on-chain and accurately verifying wallet connections.

Development of Farcaster Attestation Resolver:

Complete the core contracts for Farcaster attestations and ensure they are functional.

Development of Farcaster Attestation SDK:

Ensure the SDK is fully developed and supports third-party integrations.

Successful Integration by Critical Teams:

Critical teams have successfully integrated the Farcaster attestation functionality into their applications.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):

Coordination with the OP Foundation
Coordination with the Farcaster team

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)

Not required

Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x]  I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x]  I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x]  I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types)
[x]  I confirm that I have read and understand the [grant policies](https://gov.optimism.io/t/token-house-grant-policies/5833)
[x]  I understand that I will be expected to following the public grant reporting requirements outlined [here](https://gov.optimism.io/t/suggested-public-reporting-requirements-for-grantees/4176)

end of application --

Foundation Mission (RFP) Application

Alliance Lead: Nate
Contact info<EMAIL_ADDRESS>L2 recipient address: 0xec2f2284C3bfA30B617aCA643E244815c9D48CeE
Members:

Krish — full-stack development, SDK, Farcaster Frames
GitHub | Warpcast | X (Twitter)
Peter — full-stack development, smart contracts, EAS schemas
GitHub | Warpcast | X (Twitter)
Nate — technical documentation
Warpcast | X (Twitter) | GitHub
Ting — UX/UI, impact measurement
Warpcast | X (Twitter) | GitHub | A universal icon: Asterisk for Attestations

Collaborative work on OTTP:

Website
Documentation
GitHub

/protocol
/contracts
/ottp-sdk
/ottp-web-client

Farcaster: Warpcast
Community: Warpcast Channel
Farcaster Frames:

Attestation Frame
Example of Verification Frame
Example of Share Frame

Lens: Hey
X (Twitter)
Zora Collections: OTTP is open | Is it onchain?

Why us? We're already building the solution on the Superchain.
Our team has already shipped tools for Farcaster-native EAS attestations with the goal of benefiting the entire Superchain ecosystem.
Open to the Public (OTTP) is an open collaboration protocol built on Base. It enables any person or organization to attest to any and all collaborations (work) onchain.
Farcaster and EAS:
Farcaster Frames:

We are Day 0 transaction frame builders and have been a part of the Farcaster builder community and bi-weekly dev calls. We are one of the first attestation frames.
Any Farcaster user can create an OTTP ID (OID)—linked to their Farcaster ID (FID)—which they own forever.
Attestation Frame: FID and connected wallet is used to make onchain attestations on EAS and create an OID in one transaction. Users can attest from a different connected wallet, and it’s linked to the same FID and OID.
Verification Frame: Tagged collaborators verify it as true by making onchain attestations.
Share Frame: Users share a frame showing their OTTP ID and basic metrics, such as number of collaborators and attestations made.

OTTP SDK:

SDK v1
929 downloads to date!

User IDs
Sign in with Farcaster
Farcaster ID and EAS attestations

SDK v2 — contract completed, implementation in progress

Organization IDs
Objects (projects, proposals, milestones, etc.)
Sign in with Ethereum address
User and organization profiles

Basic Web Client:

[coming soon] This is a browser experience similar to the Farcaster Frame. View working prototype

Backdrop Build V3 and V4 Finalists:

Backdrop Build V4 project page

V4 Finalist announcement
V4 launch on Farcaster)

Backdrop Build V3 project page

V3 Finalist announcement
V3 launch on Farcaster

Gitcoin Grants 20:

OSS Web3 Infrastructure Round: 599 people helped us raise ~$2K, plus ~$4K match. View project page

Proposed solution:
Key Components:

Smart contract: secure contract-level verification of FID and connected Ethereum addresses
SDK: easy implementation
Basic web client: integration demo to use or fork
Graph: interoperable graph of user profiles, organization profiles, project pages, proposals, and more

The RFP goal is to provide assurances that the wallet issuing the EAS attestation for a project page is connected to a given Farcaster ID. We’re doing this and more.
We would like to see a world where a project attestation is not only verifiably linked to social profiles (like Farcaster and Lens) but also grants they have received from Gitcoin, Optimism, hackathons, accelerators, etc.
And even further, we want to enable use of the same project page across multiple clients, such as Gitcoin and Optimism.

We are building OTTP for everyone on the Superchain and for many use cases related to collaboration. But in the use case described in the RFP, project attestations created by a user (or an organization) would be linked to their OTTP ID and connected to any social accounts, previous projects or contributions. A project page could be repurposed anywhere and connected to anything else on the open protocol. Anything related to work/collaboration that can be proven onchain, provably connected together through the OTTP ID into a collaboration graph.
For this RFP, we will focus our efforts on strengthening the connection between Farcaster accounts and EAS attestations, including validation at the contract level.
Detailed Flow:

Sign in:

The user signs in to the app with their Ethereum address, which is connected to their OTTP ID.

Link Farcaster Account:

The user indicates they want to link their Farcaster account with OTTP.

Generate Signature in Farcaster:

The app directs the user to a secure location within Farcaster where they can generate a signature using their Farcaster custody address. Note: This can be done through a secure frame within the Farcaster interface.
Steps in Farcaster:

The user generates a signature using their Farcaster custody address.
Farcaster provides a text string containing the signature.
The user copies this text string.

Return to the App:

The user navigates back to the app.
The app prompts the user to input the copied text (signature).

Verification:

The app verifies the signature: It checks that the signature was generated by the custody address associated with the Farcaster ID.
Once verified, the app creates an onchain attestation linking the Farcaster account to the user's Ethereum address.

Create a Record:

The app initiates a transaction to record this attestation onchain.
The attestation may include an expiration date, allowing the wallet to continue making attestations using a resolver contract with the linked Farcaster address.

Session and Ongoing Verification:

The smart contract creates a session for the user, allowing them to make further calls without needing reverification for a set period.
During this session, the contract continuously verifies that the address making calls is still associated with the Farcaster ID.

View overall OTTP user flow
Step-by-step plan and expected deadlines:

Milestone 1 - July 5: Successful Integration of Farcaster Action

Description: The Farcaster action (likely a Frame) for generating signatures is fully developed and integrated into the Farcaster platform.
Criteria:

Users can initiate the action within Farcaster.
The action correctly communicates with the user's Ethereum address.
The action generates a valid Ethereum signature using the user's Farcaster custody address.
The action provides a clear and user-friendly way for the user to copy the signature.

Milestone 2 - July 10: Signature Verification and Attestation Creation

Description: The backend of our app is able to verify the signature received from Farcaster and create the onchain attestation linking the Farcaster ID with the user's OTTP-connected Ethereum address.
Criteria:

The app successfully receives and validates the signature from Farcaster.
The app creates a valid onchain attestation that includes:
The user's Farcaster ID
The user's OTTP-connected Ethereum address

Milestone 3 - July 12: Resolver Contract Deployment and Functionality

Description: A resolver contract is deployed on the blockchain and functions correctly to verify the link between Farcaster IDs and Ethereum addresses.
Criteria:

The resolver contract is deployed to the appropriate Ethereum network (e.g., Optimism).
The resolver contract correctly responds to queries about linked Farcaster IDs and Ethereum addresses.

Milestone 4 - July 26: End-to-End User Flow Testing, Using Basic Web Client

Description: The entire process, from initiating the Farcaster action to the creation of the onchain attestation, is thoroughly tested with real users using the web client.
Criteria:

Users can successfully complete the entire flow without encountering errors or issues.

Notes:

The implementation procedure may vary as we build.
Include a week buffer for each of the milestone dates.

Please list any additional support your team would require to execute this mission (financial, technical, etc.):
None required but would be helpful:

Smart contract review and security audits
Feedback on protocol design for optimal interoperability with the Superchain

Grants are awarded in OP, locked for one year. Please let us know if access to upfront capital is a barrier to completing your Mission and you would like to be considered for a small upfront cash grant: (Note: there is no guarantee that approved Missions will receive up-front cash grants.)
None.
Please check the following to make sure you understand the terms of the Optimism Foundation RFP program:

[x] I understand my grant for completing this RFP will be locked for one year from the date of proposal acceptance.
[x] I understand that I will be required to provide additional KYC information to the Optimism Foundation to receive this grant
[x] I understand my locked grant may be clawed back for failure to execute on critical milestones, as outlined in the Operating Manual
[x] I confirm that I have read and understand the grant policies
[x] I understand that I will be expected to following the public grant reporting requirements outlined here

-- end of application --

@lukema95 @Rainbow1nTheDark @nathansvan @Chomtana
The team at Lighthouse (lighthouse.cx) are very interested in this request as something we would like to implement in our product. We don’t have enough resources at the moment to submit our own application for the grant, but we would like to offer to work together with the other teams to build a real-world implementation of their proposed solutions.
We aggregate on-chain governance proposals and allow our users to comment on them, even if the underlying protocol doesn’t natively support commenting. To make this system more open, composable, and decentralized, we are working on using the Farcaster protocol to facilitate all commenting. We also make it possible to limit commenting to token-holders in order to prevent sybil attacks or misinformation campaigns, and this is where this mission request comes in. We can’t stop others from posting comments to Farcaster, but we can filter through the comments that are posted and only display the ones that meet certain criteria. In order to present a comments section where every comment is from a verified token holder, we need a way to prove that when a comment was posted, the poster was in control of an Ethereum address that held the appropriate tokens. As you can see, this mission request seeks to develop the exact feature we are looking for.
We invite the teams who win this grant to work with us to test out their solutions with real users and a real-world use case, as a way of dogfooding the results of their work. If anyone would like to discuss this more, please contact myself or @1a35e1. Good luck!

Thank you to all the builders who submitted applications for this project! @Chomtana 's alliance has been selected to carry out this Mission Request.
@Chomtana  I will be in touch directly with further instructions
For all the other builders, thanks so much for taking the time to apply 🙏 you can find other ways to get involved via contribute.optimism.io

This is lit


target switch for bmv2 make bm error

p4factory/targets/switch/bmv2/README.md shows we can build bmv2 switch through make bm. However submodule bmv2 uses autoconf tool, and error occurs as no makefile found.
sunnogo@sunyongfeng:~/research/p4/p4factory/targets/switch/bmv2$ make bm
make -C /home/sunnogo/research/p4/p4factory/submodules/bm
make[1]: Entering directory `/home/sunnogo/research/p4/p4factory/submodules/bm'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory `/home/sunnogo/research/p4/p4factory/submodules/bm'
make: *** [/home/sunnogo/research/p4/p4factory/targets/switch/bmv2/switch_bmv2] Error 2

After run ./autogen and ./configure in p4factory/submodules/bm, it works fine when make bm in p4factory/targets/switch/bmv2/.

Hi, I am not sure I understand this, as the [p4factory README] (https://github.com/p4lang/p4factory#quickstart) does say that you need to run ./autogen.sh and ./configure in the p4factory root, which will trigger these commands in the bm submodule.

Sorry for not pay attention to the p4facory outer README. It works fine after following the list command.


Encoding for passes dependencies

[ ] Tests added for any new code
[ ] Ran make fmt-fix (or had formatting run automatically on all files edited)
[ ] Documentation added for any new functionality
[ ] Entry added to UNRELEASED.md for any new functionality

Codecov Report

Merging #1260 (12a85a0) into unstable (9b5238c) will increase coverage by 0.11%.
The diff coverage is 21.17%.

:exclamation: Current head 12a85a0 differs from pull request most recent head 92f9374.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9b5238c...92f9374. Read the comment docs.


Backport cmake string cache fix to v2.7 branch

Describe the bug
If a string variables is passed when configuring a project, then the project configuration is edited, the project will then fail to work because the string variable has had it's quotes removed.
Original issue: https://github.com/zephyrproject-rtos/zephyr/issues/48950
Original fix in main: https://github.com/zephyrproject-rtos/zephyr/pull/49267
Expected behavior
For re-configured applications to still compile
Impact
Annoyance
Environment (please complete the following information):

OS: Linux
Toolchain: Unimportant
Commit SHA or Version used: 003de78ce0dd213a1c7b3d159b967fb19a12aa45

Fixed by: https://github.com/zephyrproject-rtos/zephyr/pull/49570


ReferenceError: paypal is not defined

I've tried same way as mentioned in example but whenever I load page,I got ReferenceError: paypal is not defined which is not in global context.

This seems to be a problem with Paypal script itself!
I think when Paypal script is slow in loading and returning its paypal
object, this issue will happen!
I will try to check this issue again when I have time, could you please try
again a few times! Or maybe delete the current version, and reinstall with
version 1.0.1 (npm install --save<EMAIL_ADDRESS>On Thu, Nov 9, 2017 at 18:27 Binod Tamang<EMAIL_ADDRESS>wrote:

I've tried same way as mentioned in example but whenever I load page,I got
ReferenceError: paypal is not defined which is not in global context.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/thinhvo0108/react-paypal-express-checkout/issues/13,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE-TmNqMp9gHAx-lO4OgTspmnS81ROxJks5s0sVkgaJpZM4QXqWW
.

I have just updated the latest version (@1.0.4)
Could you please try using it? Thanks!

Close this issue, which was probably fixed in version @1.0.4


Why self-closing-comp allows empty divs?

I noticed that self-closing-comp doesn't report empty divs (eg

). Is there any particular reason that it allows empty html tags? Or it's valid b/c it's valid html?

Seems like a bug to me. That should be
.

@ljharb I'd be sure it is, if there wasn't this in the doc:

That doesn't make much sense to me - but if it's documented, then it's not a bug.
However, I'd love to see an option added to this rule that requires self-closing tags for every kind of tag, including HTML tags. @yannickcr?

This is the intended behavior. This rule only enforce empty React Components to be self-closed, and HTML tags are not concerned.
I think we could modify this rule to check all type of tags by default, then add some options to filter by type (components and/or HTML tags) if needed.
It seems to be the more logical behavior to me, but it will be a breaking change.

Airbnb's React styleguide requires every empty element to be self-closed.
Alternatively, we could add an option in a minor version, and then flip the default behavior later, in a major?

Have the same issue. Is anybody already working on it? If not I'll prepare a pull request, which will add the option suggested by @ljharb to the rule.

Just wanted to leave my comment in here for future developers reaching this page.
 is not a valid HTML 4.x tag. It's the only base HTML tag (that I know of) that cannot be legally self-closing. If you use a
 it can cause very strange issues that can bubble up through a variety of frameworks (looking at you jQuery) making it difficult to trace as it does not throw distinct errors. One particular example being in IE8 where it breaks the DOM tree fairly silently.
It is always better practice to use

 even if no content exists between the tags.
As a note,
 is legitimate XHTML 1.x. However for the sake of compatibility across browsers and versions there is no reason to use it.
I realize this is ooooold world HTML but it's still very valid today. Cheers!

jsx isn’t quite html.

No arguments there, I just figure underlying it may be trying to generate a real DOM  which would then cause problems. I haven't gone through the project to know how it's generating the actual DOM element so for all I know it's properly making  but I figured this was a good place to drop the knowledge in anyway.

lol, React generates proper HTML, that's not something anyone needs to worry about :-)


[Bug] Setting skin resource from code

Calling this when skin skin resource is already set:
spine.animation_state_data_res = load(type)
spine.packed_skin_resource = load(skin)

causes this issue in logs:
connect: Signal 'property_changed' is already connected to given method '_on_skin_property_changed' in that object.

We can disconnect the signal before assigning the new skin.
Alternatively, we can set the skin, not do the signal connection when a skin was already there and trigger the signal in the c code itself.
@rayxuln  What is the purpose of the signal? The skin will not change by itself but has to be assigned manually, meaning the programmer can run the signal itself.

It's for noticing the SpineSprite to change the skin when the user changed the skin names in the packed skin resources in the editor.
Don't know why this error happened, but it's not fetal.
I'll fix it later.

You just need to disconnect signal from the old skin if it’s there.
Thomas

On Jul 20, 2020, at 8:15 PM, Rayxuln<EMAIL_ADDRESS>wrote:

It's for noticing the SpineSprite to change the skin when the user changed the skin names in the packed skin resources in the editor.
Don't know why this error happened, but it's not fetal.
I'll fix it later.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

If that signal is needed, then my pr did it wrong by removing it entirely.
Thomas

On Jul 20, 2020, at 8:15 PM, Rayxuln<EMAIL_ADDRESS>wrote:

It's for noticing the SpineSprite to change the skin when the user changed the skin names in the packed skin resources in the editor.
Don't know why this error happened, but it's not fetal.
I'll fix it later.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks. Fixed!


Pypi publish

This PR
Update to the pyproject.toml configuration for publishing to pypi

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@1727554). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #22   +/-   ##
=======================================
  Coverage        ?   85.38%
=======================================
  Files           ?       15
  Lines           ?      260
  Branches        ?        0
=======================================
  Hits            ?      222
  Misses          ?       38
  Partials        ?        0

Flag
Coverage Δ

unittests
85.38% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


StructDiscriminatedUnionAnalyzer vs. StructuredFormatDisplayAttribute

Describe the bug
I was just running a new project through the analyzers, and had thought that I might get a StructDiscriminatedUnionAnalyzer suggestion from a DU that only has empty and string members, but I got nothing.
Looking at my code, the DU in question has a StructuredFormatDisplay attribute, and removing that causes a Consider adding [<Struct>] to Discriminated Union suggestion to appear.
I'm not sure if that is intentional or not, but looking at the analyzer code I wonder if the StartsWith("Struct" at
https://github.com/ionide/ionide-analyzers/blob/e66e6038d70255ecdcc5d5321853f1a94bc57e48/src/Ionide.Analyzers/Suggestion/StructDiscriminatedUnionAnalyzer.fs#L29 is perhaps matching more things than it should?
To Reproduce
Running the analyzer against a DU such as
type LicenseValidationResult =
    | Valid
    | Invalid of error: string

results in a Hint IONIDE-012 : Consider adding [<Struct>] to Discriminated Union suggestion, but running it against
[<StructuredFormatDisplay("{DisplayText}")>]
type LicenseValidationResult =
    | Valid
    | Invalid of error: string

has no hint.
Environment (please complete the following information):
Ionide analyzers version 0.11.0

Thanks for reporting this. Yes, our check could be better I see.
Would you be interested in submitting a PR for this?

I'll have a look

This seems ok in the 0.12.0 release, so I'll close it.


Oracle 11g incompatibility - ORA-00911: invalid character

I am trying to use EF-Plus in the following environment.

.NET 4.6.1
Oracle 11g
Entity Framework v6.1.3
Oracle.ManagedDataAccess (ADO .NET) v12.1.24160719
Oracle.ManagedDataAccess.EntityFramework v12.1.2400
Z.EntityFramework.Plus.EF6 v1.4.18

When I am trying to run any future query (with parameters or not), the following error is thrown:
Oracle.ManagedDataAccess.Client.OracleException (0x80004005): ORA-00911: invalid character
EF shows correct queries in the log file and the debugger that work if you copy-paste them into Oracle Developer.
Any help would be appreciated.

Hello @dstarosta ,
We have not tested our features in all providers (especially Oracle).
I will check this one and try to fix it this weekend.
I will let you know more on Monday,
Best Regards,
Jonathan

Hello @dstarosta ,
Can you try the latest version v1.4.19
Our library should now support Oracle for Query Future.
Let me know if it's working.
Best Regards,
Jonathan

The latest version is working correctly. Thank you for the prompt fix.


Inventory default groups merge with user defined inventory groups

Defining group membership in custom inventory files does not overwrite existing default group memberships. Instead Ansible is merging them. Leaving the user no option to definitely define group memberships.
The organization of default group memberships should be reorganized. So that overwriting is still possible for the user.

According to ansible this is default behavior as groups will be merged and only matching variables will be overwritten by order
See also documentation
I'd suggest to remove default entries for openstack components as you apparently have no way of using a subset of an already allocated group, no matter the presedence.

The current approach with numbered inventory files does not work at all, right. I will investigate a script based solution to get rid of this Ansible limitation. A solution should be available during this week.


Unexpected C function call representation if function called new

I have the following C code:
#include <stdlib.h>

struct s {
    int a;
};

typedef struct s S;

S* new() {
    return malloc(sizeof(S));
}

void fun() {
    S *sptr = new();
}

I've used the Neo4j tool to get an idea to get an idea how the code looks:

The large node is a CallExpression. It should represent the function call to new().
What is surprising is:

function call is in the function fun(). Why isn't the node part of the EOG of fun?
the function code contains as code only (). What happened to its name?

The problem goes away, when the function isn't called new() if that helps. However, new() is a valid C function name without special meaning afaik.

This is/was fixed. The code is code is new() and the EOG is also connected. I suspect that we are handling the differences between C and C++ better now.


Update shikiConfig.experimentalThemes -> shikiConfig.themes

Description (required)
It appears that Astro 4.5 stabilized dual theme support for Shiki and updated this property name. experimentalThemes did not work for me with<EMAIL_ADDRESS>

Hello! Thank you for opening your first PR to Astro’s Docs! 🎉
Here’s what will happen next:

Our GitHub bots will run to check your changes.
If they spot any broken links you will see some error messages on this PR.
Don’t hesitate to ask any questions if you’re not sure what these mean!

In a few minutes, you’ll be able to see a preview of your changes on Vercel 🥳

One or more of our maintainers will take a look and may ask you to make changes.
We try to be responsive, but don’t worry if this takes a few days.

Lunaria Status Overview
🌕 This pull request will trigger status changes.

Learn more
By default, every PR changing files present in the Lunaria configuration's files property will be considered and trigger status changes accordingly.
You can change this by adding one of the keywords present in the ignoreKeywords property in your Lunaria configuration file in the PR's title (ignoring all files) or by including a tracker directive in the merged commit's description.

Tracked Files

Locale
File
Note

en
guides/markdown-content.mdx
Source changed, localizations will be marked as outdated.

Warnings reference

Icon
Description

🔄
The source for this localization has been updated since the creation of this pull request, make sure all changes in the source have been applied.


Unload model after being not used for some time

Unlike to #66 it's probably also a good idea to unload the model after e.g. 300s of not being used.
For ollama server this is the standard. My graphics card uses 40W more of power with any model being loaded.

I would like this behind a flag so I can keep the model loaded for improved latency.

Has anyone already found a solution for the problem, similar to how Ollama does it? Unfortunately, my GPU also constantly uses around 45W-50W in idle mode, which becomes quite expensive to operate given the local electricity prices (especially if the model is not used for an extended period) :S

Has anyone already found a solution for the problem, similar to how Ollama does it? Unfortunately, my GPU also constantly uses around 45W-50W in idle mode, which becomes quite expensive to operate given the local electricity prices (especially if the model is not used for an extended period) :S

FYI, I'm currently working on this

@hgruber I'm aware of this, but unfortunately, this is an upstream issue which doesn't seem resolved yet. See (this)[https://github.com/SYSTRAN/faster-whisper/issues/992]. If you find a workaround, please LMK and I'll implement it.


overflowing_add has been depreciated.

This fixes the issue that overflow_add was removed. That broke the Blake2.rs module in the Octavo-Digest module.
Also have you considered breaking these into separate git repos?

There were the following issues with your Pull Request

Commit: 3f0454fe76e2a7b927237c7364e79ce1aaff959d
Commits must be in the following format: %{type}(%{scope}): %{description}
Your subject line is longer than 72 characters

Guidelines are available at https://github.com/libOctavo/octavo/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com

Coverage remained the same at 97.674% when pulling 3f0454fe76e2a7b927237c7364e79ce1aaff959d on valarauca:master into 0fb48b47c3cf94db14a2cfba64f3355cda272fd5 on libOctavo:master.

I have considered splitting it to separate crates, but for now it is much easier for me to keep everything in one repo. In future probably this will be moved to separate repos.
About that overflowing add it is shame as now this implementation doesn't truly conform definition, but I will probably find solution to that.
Thanks for noticing.

@homu r+

:pushpin: Commit 3f0454f has been approved by hauleth

:zap: Test exempted - status

overflowing_add() doesn't seem deprecated to me.
What's the source for that claim?

It seem that there was short period when this was deprecated. Probably erroneously.
To be reverted.


Move GPU computations to compute shaders where suitable

Breakdown of tasks that need completing currently being contructed.
Being worked on in the feature/compute-shaders branch.

Just going through old issues seeing which i can close. as the conversation here has moved to the PR, would you be comfortable closing this, or do you want to keep it open?

Just thought I'd mention here that theres a few issues with the current compute branch on ps4/switch (havent tested xbox)

@huwb For me personally, I think it makes more sense to close issues when they've been resolved and the changes have been merged into the main branch. I've now linked the PR to this issue so that we have more visibility there. However, if you think it makes sense to close it now because it is already in progress, then do that for sure.

Closing this for now but leaving #230 open for reference. We have decided not to move to compute shaders (for now) while we explore other options for reducing the number of draw calls.


[Main Course] - fund data

Description
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Post for fund data(not for posting)
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

他们自己有开放给开发者的api吧？

并没有找到:(

他们自己有开放给开发者的api吧？

并没有找到:(

我找了一下，感觉很多都是非官方的第三方集成的API。好处是包含了多个网站的数据源，坏处是信息被采集和并不长期稳定靠谱。

LGTM, thanks Jiahui! 想知道网站有没有反爬机制，访问次数多了之后会不会有限制？

并没有尝试过访问太多次诶


[Bug Report]:

What operating system are you using?
Linux
What version of PHP do you use?
PHP 7.x
Where did you get the CMS code?
Github
Where are you trying to install the CMS?
Web Hosting
Which emulator are you using and which version?
AzerothCore
Describe the bug
When going to view Donation/Vote logs in the admin dashboard, it loads to https://www.theegn.com/en/admin/logs But provides a 404
How can I reproduce the problem?
Attempt viewing donation/vote point logs from the admin interface.
Screenshots
No response

Right, we currently have a problem on that, I will try to check the cause of it. Thanks for the report.


Siamese network tutorial

There's a typo in the title for feature_clusters.png - should be "MNIST".

Sweet tutorial! It worked without a hitch for me. I've added several comments above, but they're all pretty minor.

Thanks for the review. I changed the Python script to generate 10 test images of each type (same and different classes).

Awesome. If you can address the little typo I mentioned, let's go ahead and merge this.


Trustify UI - Replace Maven version range presentation

The Trustify Demo call demonstrated a screen that had version ranges expressed with Maven annotation.
They should be converted to a format that woudl be understandable to somebody without Maven knowledge.
E.g. replace
(,1.0]
with
<= 1.0

I think a good starting point might be: https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions

@carlosthe19916 maybe it makes sense transferring that issue to trustify-ui?


EventChange implementation mistakes

EventChange isn't properly implemented. As a template class, it should have its methods defined in the same file that was declared, or including the .inl (cpp) at the end of the file (hpp).
Also the EventTriggered has a typo i guess.
T newValue = &m_reference; //&
I think that the real intention was to obtain the value of the reference
T newValue = *m_reference; //*
and also the if (newValue == nullptr) has no sense in this context.
Notice that this implementation will only notify one change if any per frame. I'd recommend also adding another method to achieve this kind of behavior but for every change like an Observer-Subject pattern or wrapping the change value inside a class as suggested in this SO https://stackoverflow.com/a/3159198/7908019.

Thanks for finding this issue, should now be fixed with https://github.com/Equilibrium-Games/Acid/commit/777db1cb157a255ae09f773546ee01322a54c361. A assignment hook is probably not needed for this event type as it is used to check if the value is different from the last update time, not if it has ever had a change between the updates.


doc(k8s): add a link to doc/README.md

https://github.com/apache/incubator-apisix/blob/master/doc/README.md
And we need more comments: https://github.com/apache/incubator-apisix/pull/1218/files#r400574549

Add a link to README.md
Add some brief introduction to the doc(k8s)
Is that right？ @membphis

yes, you are right ^_^

ok，I have made some additions. @membphis


Make batch_error an atomic to avoid data races

Fixes #16583

****************************************************************

libgrpc.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++

 -------------- SHRINK --------------
  [ = ]       0 [None]    -104  -0.0%

  [ = ]       0 TOTAL     -104  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,960,753      Total (>)      1,960,729

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,878,843      Total (<)     10,878,849

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences

[trickle] No significant performance differences

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,960,906      Total (>)      1,960,882

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,881,520      Total (<)     10,881,531

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences

****************************************************************

libgrpc.so

     VM SIZE              FILE SIZE
 ++++++++++++++ GROWIN ++++++++++++++

 -------------- SHRINK --------------
  [ = ]       0 [None]    -104  -0.0%

  [ = ]       0 TOTAL     -104  -0.0%

****************************************************************

libgrpc++.so

     VM SIZE        FILE SIZE
 ++++++++++++++  ++++++++++++++

  [ = ]       0        0  [ = ]

Objective-C binary sizes
*****************STATIC******************
  New size                      Old size
 1,960,906      Total (>)      1,960,882

 No significant differences in binary sizes

***************FRAMEWORKS****************
  New size                      Old size
10,881,531      Total (<)     10,881,532

 No significant differences in binary sizes

[microbenchmarks] No significant performance differences


Integration Request: Baidu Disk Auth OAuth Support for Duplicati

Hi @kenkendk: about https://github.com/duplicati/duplicati/pull/5072#issuecomment-1959161461
After thoroughly examining the current OAuth handling mechanism on the Duplicati community forums and delving into related discussions, particularly about dealing with OAuth service transitions and issues encountered with multiple storage providers, I have come to realize the significant convenience that adding OAuth support for more storage providers would bring to users. Specifically, I am interested in how Baidu Cloud's OAuth authentication can be integrated into Duplicati's existing OAuth authentication framework.
Therefore, I would like to inquire about any plans to deploy an OAuth server that includes support for Baidu Cloud. I am willing to participate in this process, including testing and providing necessary technical support. If feasible, I would also like to establish a test server to ensure the smooth integration of Baidu Cloud's OAuth authentication.
Thank you for considering my request, and I look forward to your response.

Following up on my previous request regarding the integration of Baidu Cloud OAuth with Duplicati, I would like to suggest deploying the OAuth server on a Hong Kong-based cloud server.  This location is closer to China and might offer improved accessibility despite the Great Firewall.
Furthermore, I currently have access to a server in Hong Kong, which I am willing to provide free of charge for development and testing purposes.  This could facilitate the integration process and potentially improve the service for users in the region.
I look forward to your thoughts on this proposal.

@trueai-org I plan to progress with the C# version of the OAuth server: https://github.com/duplicati/oauth-server
See also some OAuth discussions on the forum.
The current blocker is the migration plan, which I have not progressed further on.
If you can obtain the Baidu url and scope values, it just needs to be added here:
https://github.com/duplicati/oauth-server/blob/main/ConfigurationLoader.Defaults.cs
If you can obtain these values, it should be easy to deploy a Docker instance; let me know if you need assistance or want me to host it.
There is currently not really multi-provider support for OAuth in Duplicati, but you can set the --oauth-url either globally on on the individual backups. I think your proposal is to have an OAuth server hosted in a Chinese datacenter, which means we should (eventually) support multiple providers.

Thank you for the notification; I have received the message. I will start immediately and aim to complete the task as soon as possible.


Feature/add tests

You just need to drop an .eslintrc into the test folder which extends peerigon/es5tests. Take a look at phridge's test folder for example. Than you don't need to set the mocha env explicitly or disable the linter like this


Clarify details of env vars

Provide a link to the page with an issue:
https://docs.pachyderm.com/latest/reference/pipeline_spec/#environment-variables
https://docs.pachyderm.com/latest/deploy-manage/deploy/environment-variables/#pipeline-worker-environment-variables
Describe what is wrong:
Describe the suggested changes:
A few minor improvements to discussion of env vars.

clarify that pipeline worker env vars only exist when pachyderm injects them during a job (since they change). You can't exec in and see the full list: https://pachyderm-users.slack.com/archives/GJSKMC0F6/p1576112841360300
Per soon-to-opened GH issue by JD, we should have a "Pipeline worker environment" reference doc that covers a variety of topics. The pipeline worker env half of the doc should live as part of that doc instead of under deployment.
Make sure pipeline spec Env Vars section links to full envars doc (the current one and then later, the new "Pipeline worker environment" doc mentioned above.
Anything else we need to know?

Environment:

Kubernetes version (use kubectl version):
Pachyderm CLI and pachd server version (use pachctl version):
Cloud provider (e.g. aws, azure, gke) or local deployment (e.g. minikube vs dockerized k8s):
OS:
Other:

I think we have addressed most of these concerns in the last few PRs and the resulting doc is here: https://docs.pachyderm.com/latest/deploy-manage/deploy/environment-variables/. If something is missing, feel free to reopen.


Tilde is not correctly resolved on installation script

Situation
After I've created a public SSH key, I've started the installation script with:
curl -sfL https://raw.githubusercontent.com/trento-project/trento/main/install-server.sh | bash

After I've entered the private SSH key, I got this error messages:
Please provide the path of the runner private key: ~/.ssh/id_rsa
Installing trento-server on k3s...
Installing K3s...
Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.
Installing Helm...
Updating Helm dependencies...
Installing trento-server chart...
Release "trento-server" does not exist. Installing it now.
Error: failed parsing --set-file data: open ~/.ssh/id_rsa: no such file or directory

However, the file is there.
Suggestion
It seems, the tilde isn't correctly resolved in the script. I would suggest to support this use case. In my case, ~ should be resolved as /home/cloudadmin.

Hi @tomschr, thanks for reporting this! Actually, I think this is by design, because Helm doesn't match really well with relative paths and stuff like tilde.
@stefanotorresi do you think we could improve the readme with an explicit statement about that?

Thank you Alessio @dottorblaster for your answer!
I'm not talking about relative paths. That's okay if that is out of scope. However, a tilde wouldn't count as relative. :wink: It wouldn't be difficult to resolve the tilde in the script before Helm sees it.

Well if it wouldn't be difficult we always accept pull requests and encourage folks to submit them :smile:
Anyway, we'll keep an eye on this and have a look as soon as possible, thanks!

@tomschr thanks for reporting this!
@dottorblaster  Even if it is true that this is a Helm constraint, the user shouldn't care about that, since we wrapped it inside an installer script.
Of course we will be glad to accept a PR for this!

Thanks @fabriziosestito I completely agree, the user/customer shouldn't care. It should be completely done in the script. As tilde is a valid path, we should support it (and it would be really strange if we wouldn't do that).
I've created a PR a minute ago, see #494 for details. :slightly_smiling_face:


Device Code Flow Final PR

Final major Common PR for the Device Code Flow implementation.
Added invalid_grant for DCF to ErrorStrings
Added some logging to DeviceCodeFlowCommand
Adjusted createTokenRequest() in MicrosoftStsOAuth2Strategy for DCF
Added 'mDeviceCode' to MicrosoftTokenRequest' Implemented getDeviceCode()inOAuth2StrategyAddedDEVICE_CODEtoGrantTypesinTokenRequestAdded Telemtry codes inTelemetryEventStrings`
LocalMsalController was recently moved to Common, so included following changes:
Implemented deviceCodeFlowAuthRequest and acquireDeviceCodeFlowToken in LocalMsalController
Added Exception handling in LocalMsalController
Should be merged before MSAL PR: https://github.com/AzureAD/microsoft-authentication-library-for-android/pull/1112

Parsing only used in getDeviceCode() if authority is not provided. In LocalMsalController in MSAL (Code bellow), authorityUri provided from audience object.

test is failing.

Tests passing again


Not reading the pdf file

Bug report
Whenever I'm converting an image to PDF and trying to extract the text from the converted PDF, the result from PDFplumber is blank.
What I'm doing wrong?
Step 1:

Converting an image(jpeg/jpg/png) to PDF  using the PIL
Saving the converted pdf file.

Step 2:

Open converted/saved pdf using pdfplumber.open()
Extracting text from the loaded/opened pdf file

===============================================================
Below is the code:
image_1 = Image.open(r'D:\ocr\images\barrel.jpg')
im_1 = image_1.convert('RGB')
im_1.save(r'test.pdf')
inv_pdf = pdfplumber.open('test.pdf')
print('Result:' , inv_pdf.pages[0].extract_text())
===============================================================
Terminal:
PS D:\ocr> & "C:/Program Files/Python310/python.exe" d:/ocr/testing.py
Result:
PS D:\GitOCR\ocr>
===============================================================
Below are the files converted PDF files from image file:
test.pdf
test1.pdf
test2.pdf

It’s probably worth reporting this on pdfumbers GitHub, this is pdfminer.six

Oh! Sorry

pdfplumber doesn’t do OCR (optical character recognition) - what you have done is just create a PDF with an image and no text.  If you are starting with an image and want the “text” on the image you should look at Tesseract or services like AWS Textract.  Good luck!


Console Error 'CreatureSpawnEvent'

An unknown error related to CreatureSpawnEvent to DangerousCaves v2.0.10-9
https://pastebin.com/73JYHccw
Reporting as Update would not affect this as the recent update was for the structure issue.
This error repeats several times. As a result of the errors, we have removed the plugin, for now, pending a fix. We can install updates etc and continue testing as needed to help improve this plugin.
Excited however as this plugin will bring a bunch to the table for our players taking our servers to the next level.
If you require further information please me know. Thank you for your attention to this matter.
Respectfully
EchocallingEarth
(Owner Friendlyworldserve Network©)

I've got exactly the same error as @EchocallingEarth
no problems with the structures but multiple repeated error of "creaturespawnevent" --> see attachment
I was also instant killed by "hungeringdarkness" this is maybe another bug :/
But I like the plugin and I look forward to a fix!
Regards
Emiel

Please check latest build. Seems like the problem was caused by compile error when I was commiting multiple changes.

I was also instant killed by "hungeringdarkness" this is maybe another bug :/
It's not a bug. You can configure its damage.


Mermaid sequence diagram sequence numbers unreadable

When using mermaid sequence diagrams in Obsidian with this theme, the numbers used when using sequence numbers are unreadable.
Example:

It seems that this can be styled using something like the following (used neutral-orange as a test):
.mermaid .sequenceNumber                                                                                {
    filter: invert(42%) sepia(46%) saturate(5880%) hue-rotate(11deg) brightness(97%) contrast(89%);
}

The filter was calculated via this Codepen, found via this SO question. There might be better ways to do this and use the colour variables, but this is far outside my expertise.
But it works:

The colour neutral-green also works fairly well:
filter: invert(51%) sepia(84%) saturate(405%) hue-rotate(21deg) brightness(94%) contrast(91%);

Alternatively, styling the messageLine0 and leaving the sequenceNumber alone will yield something like this:
.mermaid .messageLine0
{
    filter: invert(51%) sepia(84%) saturate(405%) hue-rotate(21deg) brightness(94%) contrast(91%);
}

Do note that there's at least also a messageLine1

This theme has been completely rewritten for Obsidian 0.16.
When you get access can you please retest? Even better, submit a pull request with the changes?

Will do once it exits insider. And no problem submitting PRs, just wasn't sure what you or others would think of the colours. I did log an upstream issue how the styling options are problematic in Mermaid for these graphs in that it's rather all or nothing.

I took a look at this and have noticed that sequenceNumbers in general look really bad in Obsidian. The are barely visible and contain no wrapping (i.e. circle) with a colored background. This behavior is in the default theme as well.
I'd like to see the default Obsidian fixed first before hacking any changes here.

And we went to 1.0 instead. Did not expect that.
I think you are absolutely correct in waiting. I would want to see changes from Mermaid and Obsidian before we can properly tackle that, since the customisability right now is, honestly, abysmal.
For reference, the corresponding issue with the Mermaid project: mermaid-js/mermaid/issues/523

Fixed in the next version. I was able to force the seqnum value to a visible color.


Add a mechanism to normalize WebIDL1 into WebIDL2

Update already incorporated in #32, closing without merging.


feat(avm)!: variants for JUMP(I) opcodes

WIP

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#8443  👈
#8441
#8440
#8439
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @fcarreiro and the rest of your teammates on  Graphite

Benchmark results
Metrics with a significant change:

protocol_circuit_simulation_time_in_ms (private-kernel-tail-to-public): 820 (-42%)
avm_simulation_time_ms (FeeJuice:set_portal): 10.8 (-30%)
avm_simulation_time_ms (Token:mint_public): 61.6 (+41%)
avm_simulation_time_ms (FPC:prepare_fee): 85.2 (+38%)
avm_simulation_time_ms (Token:transfer_public): 38.8 (+55%)
avm_simulation_bytecode_size_in_bytes (FeeJuice:_increase_public_balance): 1,722 (-24%)
avm_simulation_bytecode_size_in_bytes (FeeJuice:set_portal): 1,736 (-33%)
avm_simulation_bytecode_size_in_bytes (Token:constructor): 9,220 (-29%)
avm_simulation_bytecode_size_in_bytes (FPC:constructor): 5,367 (-31%)
avm_simulation_bytecode_size_in_bytes (FeeJuice:check_balance): 1,457 (-26%)
avm_simulation_bytecode_size_in_bytes (Token:mint_public): 3,329 (-25%)
avm_simulation_bytecode_size_in_bytes (Token:assert_minter_and_mint): 2,183 (-25%)
avm_simulation_bytecode_size_in_bytes (AuthRegistry:set_authorized): 660 (-28%)
avm_simulation_bytecode_size_in_bytes (FPC:prepare_fee): 2,611 (-33%)
avm_simulation_bytecode_size_in_bytes (Token:transfer_public): 6,296 (-29%)
avm_simulation_bytecode_size_in_bytes (FPC:pay_refund): 3,272 (-33%)
avm_simulation_bytecode_size_in_bytes (Benchmarking:increment_balance): 2,114 (-32%)
avm_simulation_bytecode_size_in_bytes (Token:_increase_public_balance): 1,728 (-23%)
avm_simulation_bytecode_size_in_bytes (FPC:pay_refund_with_shielded_rebate): 3,272 (-33%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,745
1,546
706 (+2%)
735 (-1%)
772 (+1%)

proof_construction_time_sha256_30_ms
11,831 (+3%)
3,144 (+3%)
1,404 (+3%)
1,430
1,467

proof_construction_time_sha256_100_ms
44,017 (-3%)
11,760
5,381 (-2%)
5,959 (+11%)
5,355 (+1%)

proof_construction_time_poseidon_hash_ms
78.0 (-1%)
34.0
34.0
58.0
88.0 (+1%)

proof_construction_time_poseidon_hash_30_ms
1,526
415
198 (-1%)
227 (+2%)
266 (-1%)

proof_construction_time_poseidon_hash_100_ms
5,638
1,515 (+1%)
668
728 (+2%)
746 (-1%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
4,356
7,876
14,884

l1_rollup_calldata_gas
50,220
92,954
178,120

l1_rollup_execution_gas
843,061
1,576,691
3,361,913

l2_block_processing_time_in_ms
257 (+8%)
444 (+3%)
855 (+8%)

l2_block_building_time_in_ms
11,698
22,864
45,794 (-1%)

l2_block_rollup_simulation_time_in_ms
11,698
22,864
45,794 (-1%)

l2_block_public_tx_process_time_in_ms
10,001
21,146
44,029 (-1%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
3,285 (-3%)
4,320 (+6%)

node_database_size_in_bytes
14,156,016
18,129,136

pxe_database_size_in_bytes
16,258
26,818

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Function
time_ms
bytecode_size_in_bytes

FeeJuice:_increase_public_balance
44.4 (-12%)
:warning: 1,722 (-24%)

FeeJuice:set_portal
:warning: 10.8 (-30%)
:warning: 1,736 (-33%)

Token:constructor
72.3
:warning: 9,220 (-29%)

FPC:constructor
49.0 (+1%)
:warning: 5,367 (-31%)

FeeJuice:check_balance
36.9 (-1%)
:warning: 1,457 (-26%)

Token:mint_public
:warning: 61.6 (+41%)
:warning: 3,329 (-25%)

Token:assert_minter_and_mint
616 (-4%)
:warning: 2,183 (-25%)

AuthRegistry:set_authorized
47.2 (+3%)
:warning: 660 (-28%)

FPC:prepare_fee
:warning: 85.2 (+38%)
:warning: 2,611 (-33%)

Token:transfer_public
:warning: 38.8 (+55%)
:warning: 6,296 (-29%)

FPC:pay_refund
53.7 (+24%)
:warning: 3,272 (-33%)

Benchmarking:increment_balance
1,245
:warning: 2,114 (-32%)

Token:_increase_public_balance
38.5
:warning: 1,728 (-23%)

FPC:pay_refund_with_shielded_rebate
51.7 (+2%)
:warning: 3,272 (-33%)

Public DB Access
Time to access various public DBs.

Function
time_ms

get-nullifier-index
0.164 (-4%)

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves

batch_insert_into_append_only_tree_16_depth_ms
2.20
3.87 (-2%)
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.114 (-1%)
0.109 (-2%)
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
11.4
18.0 (+1%)
30.8 (-1%)
59.7 (+1%)
115 (+1%)

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
287
543
1,055

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.109 (+1%)
0.105 (+1%)
0.100 (-1%)
0.103 (+2%)
0.103 (+1%)

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
14.6 (+1%)
26.3 (+3%)
44.3 (-1%)
83.6 (+2%)
171 (+5%)

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
109
207
357
691
1,363

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.112 (+1%)
0.106 (+3%)
0.106 (-1%)
0.103 (+2%)
0.108 (+4%)

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
16.1
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
129
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
0.106
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
72,168
668,252

Transaction size based on fee payment method
| Metric |  |
| - |  |

Merge activity

Sep 9, 3:15 PM EDT: @fcarreiro started a stack merge that includes this pull request via Graphite.


Variable __COMMAND is uninitialized

https://github.com/sasjs/core/blob/d0a0274990165f1c99281112260c652e2ed63ab9/base/mp_zip.sas#L52-L66
I believe line 54 & 67 should refer to __COMMAND instead COMMAND

Correct, great spot!  We'll get that fixed asap

:tada: This issue has been resolved in version 2.49.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


This file was made by

Would it be possible for the next version to include in the final html a line
<!-- This file was made by csvtotable https://github.com/vividvilla/csvtotable -->
?
Knowlegeable visitors to my pages have been asking me  how it was done ...

Nice visitors.

Nice visitors - yes!

A philosopher and a theologian at Theoria to Theory
a bird scientist at Bird Names


Rewrite of finisher_api Godocs

[x] Do only one thing
[x] Non breaking API changes
[x] Tested

What did this pull request do?

This PR contains a general rewrite of the method Godocs in finisher_api.go, including:

Fix grammar & spelling, improve wording
Employ consistent language across all documentation
Explicitly reference method parameters in comments
Fill gaps in explanations

I've used existing documentation from gorm.io when available
when not available I've done my best to write my own description of what the method does

limit line length to 120 chars

User Case Description

This will improve usability of GORM by providing enhanced inline documentation

@jinzhu please give this PR a review when you get the chance.
Are you interested in receiving more contributions like this?  If the GORM project is interested in improvements to documentation I would like to continue contributing.

Hello @bruc3mackenzi3
Yeah, which is really helpful, thank you for the awesome work.
If possible, you can also contribute to this repo github.com/go-gorm/gorm.io, which used to host website https://gorm.io

Thanks for your review & approval, Jinzhu.  Is there anything I can do to have my PRs reviewed sooner?  A faster turnaround on submitted PRs will help facilitate more contributions to the GORM project.  I posted a Discussion about it here as well.


Incorrect namespacing after composer require

Just installed with Composer. Not sure if the fetch process broke something, or if the repo or packagist is serving broken files.
Instead of having the namespace of CheckoutFinland, the namespace is Checkoutnland. A path-wide search-and-replace fixed the issue on my end.

Oh no, it seems my other search-and-replace caught these files too. Disregard, my bad.


Separate ports

Firstly, thanks for maintaining this repo! I've used it in several projects, and it is amazing.
At present, I would like this PR to start a conversation about a feature that is very important to me and my team: Serving documentation on one connection for an API that is on a separate connection. This was brought up at least once before in #187
We are in a similar position to @bboysathish: Our API is served on one port, which is exposed to the public via a load balancer, and our docs are exposed on different ports that is not exposed to the public web.
I've made some quick changes that will for a plugin option connectionLabels. This options will specify which connection to generate the swagger.json from, regardless of which connection is handling the request currently. Would you mind taking a look and letting me know what you think? It is just a starting point, but I want your feedback before investing more time.
Also, the interactive features of swaggerui will still not work, since the the host/port/protocol are all based on the request to docs/swagger.json. To solve this, we could also offer a way to override the host/port/protocol with static values via the plugin options, or with the connection.info data of the connection matched by options.connectionLabels.

+1 @dylancwood Thanks for making it as PR. Lets hear from @glennjones ...

Hi thanks for posting this PR glad to hear you find the project useful. I have two talks to get ready for Mon/Tue, so I will hopefully get around to looking at this in detail mid next week. I am a bit short on time until then.

Hi really like this idea, thanks for the PR. I have got to a state where it all seems works.

I have gone with options.connectionLabel: 'api' property that takes a string. At the moment we can only document one connection with one instance of the hapi-swagger plugin.

I have remove all of the options.connectionDocument idea as it does not work well with other plugins like glue and Hapi's configuration centric server setup.

You will need to set cors: true for all the api routes, so the swaggerui client-side js can access the api endpoints. This can be added within connection options.

There is a demo in the project bin\document-other-connection.js give it a go and tell what you think. I will mostly likely document this in the readme tomorrow and release a new version on npm.
Glenn
PS sorry it took me a while to look at this has been a busy couple of weeks

Thanks a lot Glen.. Please update this PR after releasing new version ..

Thank you @glennjones !

Nice job @dylancwood & @glennjones :rocket:


create type hints for ujson

This was taken mainly from the Micropython docs, with the exception of the return value of ujson.dumps(), which is actually Any.

Thank you for your pull request!
 If not, please follow the steps described at http://www.jetbrains.com/agreements/cla/ to sign it.


Unable to upload builds using Xcode 16

Describe the bug
Unable to upload builds using Xcode 16 due restriction of bitcode in the build.

Closing this issue as discussed with dev.


What am I missing? No ~/le_certs

I'm not sure what step I've missed but upon (presumably) successful run of letsencrypt_webfaction I get neither a ~/le_certs directory nor any sort of confirmation email. The relevant .well-known directory IS created inside my web app, and I can reach the generated keys via http just fine. The command completes silently, which I am taking to mean success.
Also, I have seen mention of a --support_email parameter to the command but that gets rejected.
I'm using version 2.0.0 of letsencrypt_webfaction. The described behaviour occurs both for production and when fired against the staging server.

2.0.0 changed quite a bit. In the 1.x series, this utility sent an email to WebFaction asking them to install the cert. Since then, WebFaction released an API for automatically installing a certificate. The 2.x series takes advantage of this API to automatically install the certificate. Thus, the --support_email param no longer exists, and since the cert is uploaded right into the admin, it isn't stored on disk.
If you see something in the readme that is misleading in this regard, please let me know. I just released 2.0.0 yesterday and very easily may have missed something.
Thanks!

I just searched the readme for le_certs and found a spot I missed. I just committed a fix to clean that up. https://github.com/will-in-wi/letsencrypt-webfaction/commit/83852656200fbe4b55f0811066fb9205c12cda55

Thanks @will-in-wi  for the quick response! I had no idea I was on such the bleeding edge, but I'll look for the cert to verify.. and there it is!

And I realise this is probably outside of the scope of letsencrypt_webfaction, but firefox now reports:
The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported.
for my website. Any pointers on how to fix?

I'm glad to hear it works for you! Hopefully, 2.0.0 is ready to be used by everyone, but, as with all major changes, it is possible that I missed something. Thanks for reporting the readme issue. If you see any other bugs or documentation issues, please file more tickets!