Please read the Kinic DAO white paper .
Please add any questions, suggestions, or general discussions in this post.
Project description
Kinic is the first search engine that indexes front-end content hosted on blockchain. It is an information API and discovery tool.
User requested features have ruled most of the roadmap up until now. Things like “I would love access to this data”, or “how do I improve ranking?”. Kinic won in its category in Supernova and the team has been working purely off those funds. If we want open sourced community grown products like Kinic to be able to compete in the thriving data analytics and search space, we need resources. Users are asking for the features, and we want to be able to build them effectively.
Roadmap
Expand analytics API and add frontends running on multiple chains.
‘Old-fashioned search’ will be overcome by AI driven search models. Kinic will lead this space with verifiable ZKML.
Syndication
We have reviewed the white-paper with multiple parties and it has been public for over 10 days.
On April 27th we will be closing all edits and creating the SNS configuration and proposal to match the white paper.
Kinic is a utility and governance token. Early backers such as CrowdFund NFT holder should be able to utilise their tokens. In the white-paper you will find that these people have 1/3 of their neurons with no vesting and the other 2/3 locked for vesting.
You will also find that there is no ‘developer team’ portion in the whitepaper. This is because the developer team is passing all rights and ownership to a future Kinic development organization (NPO), with the mandate of promoting and developing Kinic. Many projects in the web3 space use the option to make NPO, and we think that is the best structure for grant funding and general growth; Dfinity is one such example.
Funding target
500,000 ICP minimum to 1,500,000 ICP maximum as detailed in our white paper.
The first proposal will be for data API and DB work. The core team of developers is currently two people but we plan on adding more to be truly competitive. A primary goal is to attract all of the web3 space into hosting their front-ends on-chain rather than on cloud servers.
Community fund (CF) contribution
Kinic will seek to sell 4.2% (250,000) to the Internet Computer’s Community Fund.
Decentralization & voting power
This is in the white paper in great detail.
Security aspects
Kinic is a consumer facing dApp with no access to sensitive user data. All aspects of Kinic DAO will be open-sourced and publicly viewable. The front-end has been open-sourced on Github since Supernova. The backend search canister will be open sourced after we conclude our discussions with CanDB, and before the SNS proposal is submitted.
@bjoernek@icme
General guidelines that structured this post can be found here.
Which portion? There are lots of technical things done and documents to be made and reviewed. The technical portions have been done by the dev team. This seems appropriate for a DM rather than a forum discussion as it depends on your team and your project.
We will likely geo-block U.S. , DYOR on why… We are following a standard set by many other projects here is one example of hundreds. “only available to non-U.S.”
We are started our journey in IC ecosystem and working on product and grant. As we was running DAOs previously on another network, there was an idea to build the “open community case for SNS” when all the process from the idea, concept building to implementation are happening in real time (can participate or just observe) as an open and transparent process for all community, making all the templates, documents, masterclasses, etc done with the help of community members to the whole IC ecosystem. So later any team can use this case as an example.
Kinic has processes set up for indexing using scripts that anyone can run. Could you elaborate on what difficulties you had getting this functionality on chain?
This part does not need to be on-chain as anyone can run the scripts from anywhere. It gathers canisters that have not been indexed yet and makes a list. It checks whether a canister has been indexed yet, if not it is added to the list.
Third parties can purchase the ability to call the Kinic search API with KINIC tokens.
They will be paying for usage. This is not set up yet. But it will be xyz amount of tokens based on a call. Internal search is a big one. So blogging sites and social have shown strong interest in this. Outside of that anyone who is interested in ICP data.
Creators can claim a site via the Twitter @kinic_app
After you login you can see step-by-step directions.
dfx canister --network ic call 73j6l-2iaaa-aaaaf-qagrq-cai requestVerifyContentOwner '(principal "HERE")'
Motoko does not have a way to get canister Owner info. So there is a script that needs to be called that accepts all of the requests… also this can be run from anyone… anywhere. The best solution, is to get canister owner = caller and call it a day. We will look into this again before launch! Let us know if you think there is another way / or this has been added to Motoko.
This part does not need to be on-chain as anyone can run the scripts from anywhere
So is the idea that if it doesn’t need to be on-chain, that it’s not? There’s no other reason?
It checks whether a canister has been indexed yet, if not it is added to the list.
Could you elaborate a bit more on this? Since it’s not open source yet there’s no context and it’s difficult to understand exactly how it’s working. Is that “list” something that lives in your canister?
Internal search is a big one. So blogging sites and social have shown strong interest in this.
So a blog would pay to have Kinic search it’s own content? Why would a site use this over a free solution like flexsearch where they can index during the build step and then query the index with a worker at runtime? What’s the advantage that Kinic offers to justify the paid service?
After you login you can see step-by-step directions.
Maybe I misunderstood the Whitepaper. From reading the directions it looks like someone could claim their own canister without contacting you on Twitter and that’s only there if they need support?
Minimum number of KINIC tokens that can be staked in a neuron: 4. 1 KINIC cost is planned to 1 ICP. Distributed in 5 neurons. Did distribution of neurons is possible with these sale configuration parameters?
Edit: I mean the minimum threshold of participation in the sale of 1 ICP.
I suggest changing the minimum neuron stake in the initial configuration to 0.1 KINIC, because even when purchased for 1 ICP, it gives 0.2 KINIC per neuron + small transfer fee (0.001 KINIC per neuron)!
In this case it is better that it is not on-chain.
The indexer needs to be able to scrape the Internet (HTTPs feature helps but does not beat out scrapping tools with 8+ years of real world usage). The indexers need to be nimble. Anyone can modify the script and run it from anywhere they like; It needs to reach a specific format for it to be put into the on-chain DB.This should not be pending on an SNS voting process each time an optmial indexing procedure is realized.
Kinic DAO is not passive. Members are responsible for the workings of the DAO. If they see a canister that is not yet indexed they have the power and responsibility to index it. Many people know Javascript, therefore many people can run the indexer scripts.
In the future, more indexers can be made for cross-chain support, off-chain support, AI model testing and more. Anyone can do this without asking permission. Nimble is better here.
Could you elaborate a bit more on this? Since it’s not open source yet there’s no context and it’s difficult to understand exactly how it’s working. Is that “list” something that lives in your canister?
We have a DB (CanDB) with all of the canisters that have front-ends. The script only allows for people to append to this database. i.e. in the db we could have [a,b,c] items. The next time the script is ran, it checks that [a,b,c] exist, and if it finds ‘d’ it adds it to the DB.
Internal search is a big one. So blogging sites and social have shown strong interest in this.
This is a long standing user requested feature. Flexsearch does not work on-chain and also does not index on-chain content. So to achieve what we do with Kinic they would basically need to rebuild Kinic and add Flexsearch as their in-site specific indexer. After that they would need do design a ICP specific datastore for the index data, and port Flexsearch to work in a canister. ElasticSearch could also work for this if someone wanted to build a system from scratch.
Nuance was the first to request this. You can see what they do now. If any site could use the same procedure and algorithms to get the best content on-top, it remove endlessly recreating the wheel on a team by team basis.
Maybe I misunderstood the Whitepaper. From reading the directions it looks like someone could claim their own canister without contacting you on Twitter and that’s only there if they need support?
Right now there is no way for Motoko to check the owner of a canister.
The user makes a DFX request saying ‘Hey, I own this.’
Someone checks that indeed the person saying ‘Hey, I own this’ is the correct owner of the canister. With the DAO any member will be able to do this, in place of the former Kinic team. Kinic DAO is not passive; members are involved in the process of running the DAO.
*Future, the moment this is possible in Motoko, it will simply check the code and no one will need to call the script anymore.
It has constraints: be a not yet indexed canister, most of the data points are verifiable facts (canister id, data response length, etc). It is ‘mostly’ a deterministic process.
We could add a ZKP that gives a proof that the script was run correctly and host that proof on-chain. But this just simply saves another user’s time to rerun the script, as if A does not match B, the corrupted data is updated with the correct deterministically indexed data.
There are special cases where it needs to be removed / re-indexed.
a. bad or false data.
b. fraud sites and phishing sites.
Even if ‘indexing’ was hosted on-chain someone could read the source code and game the system. With a DAO we have multiple interested parties who can ‘flag’ content. If we reach a flag threshold, a canister can be re-indexed, overwritten, or removed all together.
Not a problem. If you want to discuss elsewhere (public Space, or not) we can go really deep into the weeds on this! It will be the best possible process we can think off for SNS.
The point here is to have a DAO that improves itself to be able to compete and win against web2… not to use established web2 services that put web3 results on the bottom; or even out right ban them.
, DYOR on why… We are following a standard set by many other projects here is one example of hundreds. “only available to non-U.S.”
