arwiki.arweave.dev Open in urlscan Pro
18.66.192.79  Public Scan

Form analysis
0 forms found in the DOM

Text Content

MENU
Home

The Arweave Project
The Open Web Foundry

Wallets

What is Arweave?

What is the permaweb?

+ View all

The Arweave Protocol
Bandwidth Sharing and Node Karma

Content policies

Gateways

How Arweave Scales: Storing All the Data on the Web

Storage Endowment

Storage Price Stabilization

Understanding Arweave's Endowment: Exploration and Simulation

+ View all

Profit Sharing
Profit sharing communities (PSCs)

Profit sharing tokens (PSTs)

+ View all

Mining
Arweave Mining

+ View all

Building on Arweave
ArDrive: Permanent Data Storage for Everyone

Bundles

SmartWeave: Arweave smart contracts

8Pin: Developer tutorial to build on the Permaweb (PART 1)

8Pin Dev tutorial. Setting up ArLocal and more (Part 2)

8pin Dev tutorial. Creating the 8pin protocol (Part 3)

8pin developer tutorial wrap up and Arweave deploy. Part 4 (FINAL)

Creating a Permaweb App with Arweave + React

Querying Arweave

Integrating Arweave-js

Posting Transactions

Integrating arweave-account

Polishing and Deploying

How to integrate ArConnect wallet when building a dApp on Arweave

What is everFinance?

Testing Tools

+ View all

Resources
Community Resources

Exchanges (AR)

How to Use ArWiki - A Brief Introduction

Cookie Policy

Privacy Policy

+ View all


menuArweave searchsettingslogin




WHAT IS ARWEAVE?

Arweave is the first protocol that enables permanent data storage. Its design
allows anyone to preserve data forever with just a single, one-time fee.

The protocol is secured by an open and decentralized network of miners, who
store and replicate data in exchange for AR token rewards. These rewards are
funded via Arweave’s sustainable endowment, ensuring that your data will always
be available, backed by a transparent and immutable risk model.

Explore the permaweb: an unbounded digital realm of pages and applications that
exist permanently, hosted on Arweave. It is a living testament to our shared
mission of building a freer internet, allowing everyone to create web apps
without any form of centralized control. On the permaweb, history and culture
are preserved, free speech is guaranteed, and the possibilities for what you can
build are limited only by your imagination.

Arweave empowers you to unleash your creativity and launch fully decentralized
applications on the permaweb with ease. Our comprehensive ecosystem of tools and
services are robust, composable, and ready to be molded to fit your vision.

Build with Arweave and be a part of shaping the future of the internet! The
ArWiki, our collective knowledge base, is hosted on the permaweb itself and open
to contributions from all. We invite you to join us. Let's build a better web,
together.




GETTING STARTED

The Arweave Project
The Open Web Foundry

Wallets

What is Arweave?

What is the permaweb?

+ View all

The Arweave Protocol
Bandwidth Sharing and Node Karma

Content policies

Gateways

How Arweave Scales: Storing All the Data on the Web

Storage Endowment

Storage Price Stabilization

Understanding Arweave's Endowment: Exploration and Simulation

+ View all

Profit Sharing
Profit sharing communities (PSCs)

Profit sharing tokens (PSTs)

+ View all

Mining
Arweave Mining

+ View all

Building on Arweave
ArDrive: Permanent Data Storage for Everyone

Bundles

SmartWeave: Arweave smart contracts

8Pin: Developer tutorial to build on the Permaweb (PART 1)

8Pin Dev tutorial. Setting up ArLocal and more (Part 2)

8pin Dev tutorial. Creating the 8pin protocol (Part 3)

8pin developer tutorial wrap up and Arweave deploy. Part 4 (FINAL)

Creating a Permaweb App with Arweave + React

Querying Arweave

Integrating Arweave-js

Posting Transactions

Integrating arweave-account

Polishing and Deploying

How to integrate ArConnect wallet when building a dApp on Arweave

What is everFinance?

Testing Tools

+ View all

Resources
Community Resources

Exchanges (AR)

How to Use ArWiki - A Brief Introduction

Cookie Policy

Privacy Policy

+ View all



LATEST ARTICLES


UNIVERSAL DATA LICENSE: HOW TO USE IT

Category: building_on_arweave 7/3/23, 2:46 PM
Reading Time: 8' 10"

The Universal Data License (UDL) enables creators to attach license rights to
their content when they post it onchain.


BASIC USAGE

In its most basic form, using the license is as simple as including the ANS-105
"License" tag and referencing the Transaction ID (txid) of the UDL.


DEFAULT LICENSE RIGHTS

By default this grants Licensee's (those consuming the content) the following
rights:

 * to copy
 * to display
 * to make public

Out of the box it does not grant the rights to:

 * distribute the content
 * make commercial use of the content
 * make derivative works of the content


LICENSE PARAMETER TAGS

Where the UDL gets interesting is in its ability to programmatically define
licensing terms for your content.

These terms are described by predefined tag names and values that you attach to
your content when posting it to Arweave. These names and values correspond with
sections of the UDL and grant licensees specific rights.


DERIVATIONS

One of the simplest rights to grant is Derivations, or the right to make
derivative works. This right is not granted by default but can be granted using
the "Derivation" tag. It has a few predefined values.

WITH CREDIT

Attaching a "Derivation" tag with the value of "Allowed-With-Credit", grants
derivation rights but only if named credit is given as per Section 7 - Credit in
the UDL.

WITH INDICATION

The "Allowed-With-Indication" tag value grants derivation rights but only if the
derived work indicates the source content. This indication is used to identify
the source content as compared with Credit which names the creator. How this
indication is made is up to the Licensee depending on where the derived content
is being distributed.

WITH LICENSE PASSTHROUGH

The "Allowed-With-License-Passthrough" tag value grants derivation rights but
only if the license parameters of the content are preserved in the derivation.

WITH REVENUE SHARE

Finally, it's possible to allow derivations if the derived content contributes a
portion of its revenue to the contents owner. This is done using the
"Allowed-With-RevenueShare-[.0-9+]%" value for the "Derivation" tag. The [.0-9+]
in this instance indicates the allowable characters for defining a percentage.
e.g. 01, 1.0, 33, 51.5 are all valid percentages to indicate.

"Derivation" : "Allowed-With-RevenueShare-25%" 


The above is an example of allowing derivation if 25% of the revenue generated
by the derivation is shared with the content owner(s).


COMMERCIAL USE

Another configurable right is Commercial Use as indicated by the
"Commercial-Use" tag. There are two predefined values that relate to sections in
the UDL.

ALLOWED

Specifying a value of "Allowed" for the "Commercial-Use" tag grants the rights
of licensees to use the content for Commercial use.

ALLOWED WITH CREDIT

Specifying a value of "Allowed-With-Credit" for the "Commercial-Use" tag grants
the rights of licensees to use the content for Commercial use.


LICENSE FEE

Along with "Commercial-Use" rights is the ability to describe a one time or
monthly license fee associated with that use. If no "License-Fee" tag is present
there is no fee for the license, if it is the UDL defines one of two values.

MONTHLY

If a monthly fee is desired, using "Monthly-[.0-9+]" as the format for the value
of the "License-Fee" tag. The numerical portion of the value is the amount of
[Currency] to be paid to the assets owner(s) each month. The[Currency] tag is
described later in the document.

"License-Fee" : "Monthly-200"


The above example defines a monthly license fee of 200 [Currency] to be paid to
the owner(s) of the asset.

ONE TIME

Similarly to the Montly License fee it's possible to indicate a one time up
front license fee to be paid to the owner(s) with the format "One-Time-[.0-9+]".

"License-Fee" : "One-Time-1500"


The above example defines a one time license fee of 1500 [Currency] units to be
paid up front.


CURRENCY PARAMETER

As payments can be denominated in a variety of different units the "Currency"
tag indicates which denomination the owner(s) is/are expecting payment in. It
should note that the currency used should be compatible with the owner
address(es) attached to the asset.

If the "Currency" tag is not provided, the currency defaults to the $U token on
the Arweave network. The owner address(es) should be Arweave network addresses
accordingly.

"Currency" : "AR"


The above example overrides the default $U token as currency and instead
denominates the payment terms in AR token.


LICENSE RIGHTS DURATION(S)

There is also an "Expires" tag that can be added to transactions to indicate
when the the license terms indicated by the tags expire. The value for the
"Expires" tag is designated in years following the format "[0-9+]".

"Expires" : "5"


The above example indicates the parametrized license terms expire 5 years after
the content was posted to onchain.

Additionally, it is possible to define tags tags which set specific durations
for "Commercial-Use" and "Derivation" terms using the following formats.

The tag name is formatted to the following
"[Before/After]-[0-9+]-Years-Derivation" and the value must be one of the valid
values for the "Derivation" tag. There can be one or more of these duration
tags.

              "Derivation" : "Allowed-With-RevenueShare-30%"
"After-1-Years-Derivation" : "Allowed-WithRevenueShare-10%"
"After-5-Years-Derivation" : "Allowed-With-Credit"


The above example shows Derivation terms that are allowed with a RevenueShare of
30% in the first year, 10% for the next 4 years, and becomes "Allowed With
Credit" from 5 years on.


PAYMENT ADDRESSES

The UDL supports a variety of payment methods and means of indicating which
owner addresses to provide payment to.


TXOWNER

By default if no "Payment-Address" tag is present the address to receive payment
is the one that signed the transaction that posted the content to Arweave.


PAYMENT ADDRESS TAG

If present, the "Payment-Address" tag overrides the signer of the transaction as
the address to receive payment.

"Payment-Address" : "89tR0-C1m3_sCWCoVCChg4gFYKdiH5_ZDyZpdJ2DDRw"


The above example shows indicating a separate Arweave wallet address for payment
than what was used to post the content transaction.


ATOMIC ASSET CONTRACT

Another possibility on Arweave is that the content transaction also be attached
to a smart contract. If the smart contract tags are present the contract state
is considered authoritative as to the current ownership status. Including
proportional ownership if the contract is tokenized.


PAYMENT MODE

If there is a smart contract attached to the content transaction, it may be that
there are several owner addresses with claims to the license fees and/or revenue
share. If that is the case the creator may specify a "Payment Mode" tag. If not
present, the payment due defaults to the address designed by the
"Payment-Address" tag.


RANDOM DISTRIBUTION

If "Random-Distribution" is provided as the value of the "Payment-Mode" tag, a
random address is selected from the attached contract and paid the full fee due.
This randomness should be a pro rata distribution based on the portion of the
asset each address owns. The contract may define a distribution function that
the licensee can invoke.


GLOBAL DISTRIBUTION

If "Global-Distribution" is provided as the value of the "Payment-Mode" tag then
the fee due is split up proportionally to to the ownership stake of each address
in the content and an individual payment is made to each address with that
amount. The contract may define a distribution function that the licensee can
invoke.



Read full article


HOW ARWEAVE SCALES: STORING ALL THE DATA ON THE WEB

Category: the_arweave_protocol 4/27/23, 2:54 AM
Reading Time: 4' 28"

Scalability is a primary concern when it comes to blockchain protocols, as it
can determine the likelihood of long term success. This article delves into
Arweave’s scalability and how it scales to storing all the data on the web.


PERMANENCE AND UNIFORMITY OF TRANSACTIONS

Arweave’s scalability is derived, in part, from the permanence of its data set.
Because all data is stored forever with a uniform set of rules and expectations,
each data transaction can be processed and finalized with the same set of
parameters.

This uniformity enables the bundling of transactions, making it possible for
multiple transactions to be combined together into one. This process is defined
by Arweave Network Standard -104. We will revisit bundling later on in this
article.

To better understand transaction uniformity, it’s useful to contrast Arweave's
decentralized permanent storage model with other models, such as contract-based
storage where limited block space leads to fee markets to bid for transaction
inclusion.

Individual data items on contract-based systems need to be committed with
qualifying information: how long the storage term is, who should store the data,
how many replicas, etc. The effect of this is that each transaction needs to be
adjudicated separately -- similar to the mechanisms used by smart contracts more
generally. The variability of parameters used by contract-based storage
negatively impacts its potential for scalability, because as the number of
concurrent storage terms grows, so does the required computational power for
maintaining the corresponding data items on the network.

Instead of needing to adjudicate millions or billions of contracts which all
have their own terms, Arweave has just one: pay once, store forever. Because
Arweave’s only storage term is permanent there is no increase in bookkeeping or
computation from adding data items to the network. Once included, every new data
item gets incorporated into the same mining process as previous data items. The
only mining resource that increases is the amount of drive space required to
store a full dataset.

How does Arweave accomplish this feat? Because the entire dataset is immutable
it can be represented as a single uniform “data lake”, broken into 256KB chunks.
These chunks can all be represented as a single merkle tree whose root and
branches are updated with each new block added to the network. This uniform
representation of the entire dataset enables the protocol to manage the
proofs-of-storage produced by Arweave miners. It also eliminates the
computational overhead of managing the bookkeeping of storage terms used by
smart-contract based storage networks.




INFINITE SCALING USING RECURSIVE BUNDLES

On Arweave, a potential scaling bottleneck occurs when payments are processed
for adding data. Arweave is structured similarly to a blockchain and cannot
process unlimited payments simultaneously. The network processes a maximum of
1000 transactions per block (including payments for data storage as well as
token transfers), with a block time of 2 minutes.

This is where bundling transactions becomes relevant. Bundles can contain an
unlimited number of transactions, and only count as one Arweave transaction in a
block. Each bundle is settled in one payment transaction on the Arweave network.

A number of services now exist to perform this bundling service, for example
Bundlr Network and EverVision HQ . Presently, they upload millions of pieces of
data per day across just a few thousand Arweave payment transactions.

Eventually, when Arweave reaches the scale of the centralized web, there will be
more bundles being submitted than the 1000 transactions possible in Arweave
blocks. At that point, because the bundles are recursive, they can be bundled
together again!

This leads to trees of data with infinite depth that are committed to the
network in a single Arweave transaction. This system could potentially ingest
the entirety of the web's data in one bundled transaction!

In summary, Arweave scales without fee markets, forever, thanks to trees of
bundled data with infinite depth.



Read full article


WHAT IS ARWEAVE?

Category: the_arweave_project 4/26/23, 7:54 PM
Reading Time: 1' 29"

Arweave is the first protocol that enables permanent data storage. Its design
allows anyone to preserve data forever with just a single, one-time fee.

The protocol is secured by an open and decentralized network of miners, who
store and replicate data in exchange for AR token rewards. These rewards are
funded via Arweave’s sustainable endowment, ensuring that your data will always
be available, backed by a transparent and immutable risk model.

Explore the permaweb: an unbounded digital realm of pages and applications that
exist permanently, hosted on Arweave. It is a living testament to our shared
mission of building a freer internet, allowing everyone to create web apps
without any form of centralized control. On the permaweb, history and culture
are preserved, free speech is guaranteed, and the possibilities for what you can
build are limited only by your imagination.

Arweave empowers you to unleash your creativity and launch fully decentralized
applications on the permaweb with ease. Our comprehensive ecosystem of tools and
services are robust, composable, and ready to be molded to fit your vision.

Build with Arweave and be a part of shaping the future of the internet! The
ArWiki, our collective knowledge base, is hosted on the permaweb itself and open
to contributions from all. We invite you to join us. Let's build a better web,
together.



Read full article


POLISHING AND DEPLOYING

Category: building_on_arweave 4/26/23, 7:54 PM
Reading Time: 17' 25"


POLISHING AND DEPLOYING

Next up we'll be implementing a few features that bring our app much close to
being finished and having a viable, self contained, featureset.


POLLING FOR UPDATES

Now that we’re dispatching new posts to arweave, it would be nice if we could
view the new tweet in the timeline without having to refresh manually in the
browser repeatedly until it appears at the gateway.

To accomplish that we’re going to poll the gateway until the new transaction
appears. A naive implementation would be to spam GraphQL queries at the gateway
one after the other generating a lot of wasteful requests. Aside from being
wasteful there’s some good reasons not to do that, the https://arweave.net
gateway has rate limiting in place that limits the number of graphQL queries you
can make every 5 minutes. Hammering it this way may cause it to start rejecting
your requests, disabling the app.

To avoid being rate limited we’re going to use a simple form of exponential
backoff when polling the gateway.

Open up src/App.js and add a new function at the top of the file below the
imports.

async function waitForNewPosts(txid) {
 let count = 0;
 let foundPost = null;
 let posts = [];
 
 while (!foundPost) {
   count += 1;
   console.log(`attempt ${count}`);
   await delay(2000 * count);
   posts = await getPostInfos();
   foundPost = posts.find(p => p.txid === txid);
 }
 
 let i = posts.indexOf(foundPost);
 posts.unshift(posts.splice(i,1)[0]);
 return posts;
}


We’ll take as a parameter the transaction id of the post we dispatched. We’ll
continue to query graphQL until it shows up and we can confirm arweave knows
about the transaction.

First we set up some working variables that we’ll need to accomplish our goal.
Next we set up a while loop that continues to loop until we find a postInfo with
a txid that matches the transaction id passed into our function.

Aside from posting a graphQL query to the gateway via getPostInfos() , the other
function this loop implements is our simplified exponential backoff function.
Each loop iteration we increment our count variable and use it to calculate how
much time to delay before calling getPostInfos() again.

Below is a graph of the number of seconds of delay for each iteration of the
loop indicated with blue bars. The red bars show what a linear polling cycle
would look like if we polled every 2 seconds. You can see how by the 20 second
mark linear polling would have made 8 calls, but our exponential backoff
(backing off +2 seconds each attempt) would have only made 4. Those 4 calls
would have been almost as responsive as linear polling early on, but backed away
if the gateway was slow to respond. This reduces the chance of running headlong
into rate limiting and also gives the gateway some breathing room if it’s
experiencing heavy load.



Back to the waitForNewPosts() function. When getPostInfos() returns with results
from GraphQL, we search them to see if we can locate our new transaction.

foundPost = posts.find(p => p.txid === txid);


Our find() looks through all the postInfos returned by getPostInfos() and looks
to see if any of them have the transaction id (txid) we’re looking for. If so,
it gets assigned to foundPost, causing the loop to exit.

Lastly because there may be several pending posts (those with a height of -1)
the sort order returned by getPostInfos() might not put the one we’re looking
for at the top of the list. So we splice() our foundPost out of the list and
unshift() it to the beginning, forcing it to display as the first post in our
timeline. Now it’s time to get it wired up.

The <NewPost /> component will call onPostMessage() when it dispatches a new
transaction to arweave, but we want to refresh our postInfos state all the way
back up in our App component. So, we’ll have to do the plumbing to get that
event back up to the App component. Starting in App, add a function right below
the react state declarations to handle the event.

async function waitForPost(txid) {
   setIsSearching(true)
   let posts = await waitForNewPosts(txid);
   setPostInfos(posts)
   setIsSearching(false);
 }


There are a number of ways to handle this, but for the purposes of this tutorial
we’ll show the progress spinner while the exponential backoff function (
waitForNewPosts() ) is waiting. Once it completes we’ll update our postInfos in
React and toggle the spinner off.

Locate the declaration of the <Home /> component and add the following
onPostMessage={waitForPost} the full declaration should look something like
this.

<Home
 isWalletConnected={isWalletConnected}
 isSearching={isSearching}
 postInfos={postInfos}
 onPostMessage={waitForPost}
/>}


Now we need to pass that same property on to <NewPost />. Locate the Home
component function that declares <NewPost /> and modify its properties to look
like this.

<NewPost 
 isLoggedIn={props.isWalletConnected} 
 onPostMessage={props.onPostMessage}
/>


It’s time to test!

Switch to the browser tab containing the dApp, open the developer tools so you
can watch the console log. Then post a message and observe the polling in
action. It should take a couple of queries before the new post shows up, but
once it does it should appear at the top of the timeline, the spinner should
hide, and the new Post component should be reset (and editable again).


ADDING PROTOCOL FEATURES

One of the exciting things about using existing protocols built on arweave is
that they are open and permissionless. You are free to build on top the existing
tags/transactions adding some of your own. This way you can incrementally
increase the functionality of the protocol without breaking any existing apps.

In twitter hashtags are an important feature that enable users to organically
create categories of tweets. The original Public Square protocol doesn’t make
any mention of categorizing posts, but that doesn’t mean we can’t add it!

Let’s add the ability for users to add a “topic” to their post (carefully
avoiding the word “Hashtag” which some large corporation has no doubt
trademarked)

These “topics” will be clickable links like hashtags that filter out any post
that doesn’t include that topic. To keep things simple and organized we’ll allow
just one topic per post.


DISPLAYING A TOPIC LINK

Head over to src/components/Posts.jsx and modify the <PostItem /> component.
Right after our existing React.useEffect(() => { function we added back in the
Handling asynchronous state section, add the following function.

const renderTopic = (topic) => {
 if (topic)
   return (<Link to={`/topics/${topic}`} className="postTopic">#{topic}</Link>)
}


Then, a little lower in the file right after the “postRow” div, add this line

{renderTopic(props.postInfo.topic)}


This will add a React <Link /> component to our post view if
props.postInfo.topic is defined. This means we need to modify the
createPostInfo() function to include support for a topic tag. Open up
src/lib/api.js where we can make that change. Somewhere in the top section of
createPostInfo() add the following declarations.

const topicTag = node.tags && node.tags.find((a) => a.name === 'Topic');
const topic = topicTag ? topicTag.value : null;


This code attempts to locate a ‘Topic’ tag in the tags array and initialize a
topic variable with its value if the tag is found. Next, update the postInfo
declaration to include a topic field. The final declaration should look
something like this.

 const postInfo = {
   txid: node.id,
   owner: ownerAddress,
   topic: topic,
   height: height,
   length: node.data.size,
   timestamp: timestamp,
   request: null,
 }


If you test the app now you may notice that suddenly your timeline contains
posts with topics. That’s because other people doing this tutorial before you
have made this change and posted transactions with the topic tag.

If you click a topic link, you’ll see it redirects to the topics section of the
dApp but it’s not filtering properly (it is changing the URL correctly though).
Don’t worry we’ll fix that in the next section, Dynamic Queries. Before we do
that though, let’s add the ability to specify a topic in the <NewPost />
component.

Navigate your code editor back to src/components/NewPost.jsx and add the
following React state to the top of NewPost (alongside postValue and isPosting).

const [topicValue, setTopicValue] = React.useState("");


This is where we’ll store the post topic so we can set up a ui that rebinds
anytime topicValue changes.

Below that we need to add a helper function to validate our topic input to only
allow alphanumeric characters and dashes.

function onTopicChanged(e) {
 let input = e.target.value;
 let dashedTopic = getTopicString(input);
 setTopicValue(dashedTopic);
}


Next uncomment the “topic” divs that are the first child of <div
className="newPost-postRow">. These exist in two places, one with an onChange
handler for the active form, the other with disabled={true} for the disabled
form. After uncommenting the code will be enabled like this…

<div className="topic"
 style={{color: topicValue  && "rgb( 80, 162, 255)" }}
>
 #
 <input
   type="text"
   placeholder="topic"
   className="topicInput"
   value={topicValue}
   onChange={e => onTopicChanged(e)}
 />
</div>


Also uncomment the // setTopicValue(""); line in onPostButtonClicked(), this
will reset the topic field to its default state after we make a post.

Now when you sign into the dApp with your wallet you’ll see a place to enter a
topic in the NewPost view.



And when you input a topic it should do input validation and highlight the text.



Finally let’s make sure any topic the user inputs is added to the transaction as
a custom tag to the transaction.

Scroll up to the onPostButtonClicked() function and add the following lines of
code below where we specify the other transaction tags.

if(topicValue) {
  tx.addTag('Topic', topicValue);
}


This way we only add the "Topic" tag if the user provided a topic value. That’s
it, we’re done.

Try a test post to see if your topic shows up in the timeline.

Next up, it’s time to fix those topic links!


DYNAMIC QUERIES

GraphQL queries are pretty easy to parameterize. We can modify our existing
buildQuery() function in src/lib/api.js to take a few arguments to further
filter the results. Modify the beginning of the buildQuery() function to look
like this.

export const buildQuery = ({count, address, topic} = {}) => {
  count = Math.min(100, count || 100);
  let ownersFilter = '';
  if (address) {
    ownersFilter = `owners: ["${address}"],`
  }
 
  let topicFilter = '';
  if (topic) {
    topicFilter = `{
      name: "Topic",
      values: ["${topic}"]
    },`
  }
 
  const queryObject = { query: `{
    transactions(first: ${count}, ${ownersFilter}
      tags: [
        {
          name: "App-Name",
          values: ["PublicSquare"]
        },
        {
          name: "Content-Type",
          values: ["text/plain"]
        },
        ${topicFilter}
      ]
    )
   ...


These arguments allow us to filter the query results in three important ways.

 * We can specify a count argument that will limit the results to a specific
   number. By default it will default to 100 (the maximum the
   arweave.net/graphql endpoint will return) if no count is provided. You can
   see more documentation on how the first parameter works as well as pagination
   and cursors in the graphQL guide.

 * Specifying an address argument will filter the results limiting them to only
   those transactions owned by a particular address. You can read more about
   owners address filtering here.

 * Finally a topic argument will enable us to limit the results to only those
   transactions with a “Topic” tag whose value matches our argument. You can
   read more about filtering by tags here.

Then, open up src/App.js and modify our getPostInfos() function so it can pass
through address and topic values as query filters.

async function getPostInfos(ownerAddress, topic) {
 const query = buildQuery({address: ownerAddress, topic});


Poof! Now when we go back to the browser and click on users wallet addresses or
topic links it takes us to a page with filtered results. How? Well we cheated a
bit, the <TopicResults /> and <UserResults /> components in the sample project
have been passing ownerAddress and topic filters as arguments to getPostInfos()
the whole time. Until we added these parameters javascript was just ignoring
them.

The React implementation is all there in src/App.js for you to inspect if you’re
curious.


INTEGRATING AVATARS

<Coming soon>


DEPLOYING TO ARWEAVE

Finally, we’ve got a working application but it’s just on our machine, we want
to deploy it permanently on arweave making it fully decentralized.

How do we do it?

First if you're still running the app in development mode, hit ctrl+c to cancel
it. Next run the build command with.

npm run build


This will make a production version of the app in a build directory. Next up,
it’s time to run some arweave tooling to deploy our build. While there are other
options, for this guide we are going to use a tool called arkb.

npm install -g arkb


arkb will allow us to deploy our build directory to arweave. Each file will
become its own transaction posted to arweave. On top of that arkb takes
advantage of a gateway feature that allows for users to post a path manifest.
Path Manifest files link separate transactions together at a “root” transaction
and tells the gateway to treat them as though they are all relative to a single
base path. Other than knowing this is how the gateway is able to collect a bunch
of disparate transactions into a single path to serve as a site, there’s not
much more for us to do. Arkb takes care of the rest.

Time to deploy our app!

arkb deploy ./build --wallet ~/arweave/testWallet/PeZMM2...hE93S0.json


The wallet file name has been abbreviated here to fit nicely into one line, but
when you run specify the wallet path you’d use the fully qualified name for your
wallet file. It does cost to deploy to arweave so make sure you have some AR
tokens in that wallet.

Upon running the command you should be presented with a summary of the files to
be uploaded.



There may be more or less files depending on if you’ve uploaded before. Arkb
makes every attempt not to post files that have already been. Instead it builds
a new path manifest that links to the existing file.

Once deployed you’ll get a confirmation



The link provided links to the path manifest file transaction. Following this
link will load up our public square app, permanently deployed on arweave. (after
a minute or two for the file bytes and manifest to be processed at the gateway)

You’ll notice that the gateway will redirect you to an odd looking url.
Something like this
https://xcnkkqqbwbk6b5nirwjxq6tcjmetlokwigma3okjofk2syzai27q.arweave.net/uJqlQgGwVeD1qI2TeHpiSwk1uVZBmA25SXFVqWMgRr8/#/.
It’s the same transaction id, but now it’s being served from a unique subdomain
of arweave.net. This is for security reasons, if all sites/dApp deployed to
arweave were served from the same arweave.net domain then they would all share a
localStroage cache in the browser. This would give a malicious dApp access to
data stored by a benevolent app. So, in order to preserve the security sandbox
for each dApp, arweave.net redirects each transaction to their own unique
subdomain.

Thats it. You're done. You now have your own decentralized, permanently deployed
front end to the Public Square protocol on arweave. You can take the shortened
version of the link that arkb printed out and send it to your peers to see what
they think.

The version I deployed creating this tutorial is deployed here...

https://arweave.net/HWxmM0XwdKAlXNfGCcJIQ5is3mbmIq0thLlB3Jc00H8

...or if you prefer the much easier to remember...

https://public-square.arweave.dev

Deployed using ArNS which you can learn more about here
https://pages.arweave.dev.

Welcome to the permaweb🐘

-DMac

Previous Overview 04 Integrating arweave-account Overview



Read full article

More articles

Powered by

Follow us on
 * Cookie Policy
 * Privacy Policy
   

ArWiki v2.0.5
Please enable JavaScript to continue using this application.

Show menu
Search
Settings
Login

cookie This website uses cookies and similar technologies to enhance your user
experience.

Accept   Learn more