I have an idea about how to implement it, using self-balanced binary trees. I still don’t know if the implementation will be efficient enough to make transfers but I presume it will be.

Show thread

What about a non fungible token, where you can transfer them in batches as large as you want. They are like fungible tokens, but each individual token has a sequence number. Very much like dollar bills.

Is there any practical use case for such interface?

Some idea: you transfer some tokens through a bridge. The equivalent is minted in the other side of the bridge, but using this interface. Each token will keep track of the exact tx where it was deposited, and could be treated differently.

@mob yeah; that ain’t easy to do; but I have some idea.

The basic idea of how it works is that I do binary search finding the blocks where the nonces in your access key changes! Meaning that a tx was done from your account.

Ofc this means that you will only see txs signed by you; I plan to handle separately ft receivals; but in a similar way: tracking balance changes.

Notice that this explorer doesn’t use any other backend than a near rpc endpoint.

@mob here is the live demo:


It may take some time to fetch your txs if there are too many! already have an idea to download faster the recent txs so we can get faster feedback.

@mob here is the live demo:


It may take some time to fetch your txs if there are too many! already have an idea to download faster the recent txs so we can get faster feedback.

@rozbor I’ve looking for implementing a fair and decentralised casino for some time now.
NEAR exposed random numbers that can be used (with caveats).

The decentralised part would work as follows: everyone can put the money as the house; and gamblers play against that money (odds are always against gamblers ofc). This is a house contract; and audited games can use resources from the house.

While thinking of this; not only this mini-explorer can used this registry; but also other explorers; off-chain apps and most importantly wallets that are making you sign nearly opaque information.

However having a common registry requires an standard! Before jumping into developing a NEP; I'd love to get your input on this.

Here is a first iteration:

Show thread

Here is the source code: github.com/mfornet/near-mini-e

The most exciting feature for me however; is creating an on-chain registry that allows me to understand the content of a tx; and display better information for it. Wether it is an NFT transfer; a near land interaction; a berryclub farming action or a swap in ref finance. Building this registry as a community would be great;

Show thread

Here is an idea of a project that I recently started to build. A lightweight explorer that doesn't use any other backend than a NEAR nodes. It allows you to explore all txs initiated from a single account.

This is a preview about how it looks like

Is there any docs or source code available for adtoken. Nothing to be found on thewiki.near.page yet.

We just created a bounty program in Aurora. github.com/aurora-is-near/boun.

Looking forward to meet engineers willing to contribute and get rewarded for that. If you are interested please ping me.

For now we just have one task. But feel free to explore open issues on Aurora repositories/ecosystem and ping me to open a bounty on those.

Wdyt @zavodil @mob
If you think this viable we can discuss how to do it an open a bounty on this.

Show thread

On the same line of this proposal: github.com/near/bounties/issue.
It would be nice to build signed proofs of events happening on near.social (like toots and maybe DM) so we can integrate them easily with contracts on NEAR. It will work with an oracle that verifies the content is signed by the platform. We still need to trust whoever runs the infrastructure doesn’t go rogue, but we can iterate on this later.

There are direct messages in Near social. So we can easily introduce messages between NEAR accounts and even attach some tokens there.

Nice idea.
It would be nice to be able to send a message to a NEAR account (via an onchain app potentially) and being able to read them and answer them from here.

Which feature should we implement first in the Near.Social dApps catalog? -social

I'm Marcelo, previously NEAR Core Engineer, and Rainbow Bridge 🌈 developer, currently hacking on Aurora as a lead of the protocol team.

I speak Spanish 🇨🇺 🇪🇸 and still enjoy participating in programming competitions.

Looking forward to connect with more members of NEAR ecosystem.


Social network for NEAR ecosystem