Thanks @patnorris, I’ll try and have a thorough read of the whitepaper over the next few days.
Regarding governance (including milestone fund management), do you have any bug bounty programme or any other incentive structure to encourage skilled members of the community to put time into reviewing proposals? This would help give followers a diversity of options, and avoid centralising control (allowing the milestone management process to operate more effectively).
I’ve made it through the whitepaper. Very impressive and exciting stuff. When I have some more time I plan to play around with a local deployment of IConfucius - I’ve got lots of ideas for gamifying and tokenising usage of a service like that.
Separate to that, governance as a service is something I think there is huge potential in longer term. I’m very bullish on the tech that you’re building.
A couple of questions pop out from my read of the whitepaper.
The onicai SNS funds development service providers – like, but not limited to the current Development Team – to build, maintain and support the core technology components, integration tools and products for Proof-of-AI-Work / Chain Fusion AI implementations on the Internet Computer.
The products created by the development service providers direct their revenues back to the onicai SNS. They can either stay under full control of the onicai SNS or the SNS can opt to spin them off into their own, separate SNS and governance structure.
Could you give an example of another type of development service provider that you envision. Could you imagine DFINITY occupying this sort of role at any point?
Related or not, I note this line from Dom’s DFINITY 2.0 announcement which leans heavily into IC-centric AI.
The other initiative planned is called Convo, which is currently in stealth. ←
Hi @Lorimer , thank you for your feedback!
That’s great to hear. Please let us know if you want to discuss ideas for IConfucius and/or governance as a service at some point 
We definitely see a bounty program as an exciting opportunity for the SNS. The main category we had thought about was development bounties for solutions that extend the onicai DeAI Platform (there are a few lines on this in the Whitepaper) but we agree that bounties for governance work would be great to have too. Especially also given the codebase and thus related proposals will be quite involved (at least at times). Thanks for sharing this idea!
Some developers or teams might “outgrow” the bounty program and with the established trust through their contributions could then also become a development service provider that follows the milestone based development process. In addition, existing IC teams that the SNS wants to partner with (e.g. integrate the solutions, include their solution on the DeAI Platform, extend capabilities via their tech and apps) could be development service providers on a project basis as well. It’s an interesting idea to potentially have DFINITY also contribute as a development service provider here (top of my head, this could make sense for integrations with Caffeine AI or UTOPIA). Did you have ideas in mind how DFINITY might fill this role?
As detailed in the Go to Market Strategy section, some of it also banks directly on the alignment with DFINITY 2.0’s AI strategy (e.g. Caffeine AI, but also UTOPIA), plus in general we believe that there will be many exciting opportunities for DeAI in the IC ecosystem (and the onicai SNS would be well positioned to contribute here), e.g. also because of Chain Fusion AI and the capabilities this offers.
The onicai_sns_init.yaml has been finalized. All TODOs have been replaced:
We are currently hard at work to prepare the funnAI application for the SNS:
@Lorimer ,
you should now be able to do more of your analyses. Once code has been fully open sourced, we will put another note here.
@rem.codes,
We are interested how you use dfx sns to validate the sns_init yaml file. What commands do you use? We’re going to do an SNS test flight, but are there other things we can do?
I think high performing LLMs (such as those generating complex and useful code) will be better hosted off-chain for a long time, until there’s more utility in the AI-generated dapps, and more responsibility and trust placed in those dapps by more users, such that verifiable model provenance and tamper-proof weights become important enough to justify the costs (hopefully shrinking costs and growing capacity) for running models on-chain.
I personally think that on-chain LLMs are currently well-placed for simpler tasks where either:
I think an example of the first case would be users who wish to interact with virtual girlfriends, or any other scenario where one might want to engage in conversation that is verifiably private. A user also being able to own the canister that hosts such virtual entities is also a value proposition. The fact that onchain models are slow is not a problem in this space, because humans are often even slower (it only adds to the realism). Users could achieve the same sort of thing by hosting an LLM locally, but that would require more work on their part (particularly if they want portability).
I think an example of the second case would be a model that is instructed to guard a secret and users compete to convince the model to divulge that secret (this could take many different themes).
These both feel like low hanging fruit that I could imagine taking off if the UX is right.
I have no idea what DFINITY have planned for their ‘Convo’ project, but I’d be surprised if it isn’t focusing on on-chain conversational models.
Great, thanks @patnorris. Will there also be verifiable build instructions? This will allow the community to confirm the source code that produced the WASM in each of the canisters being handed over.
So if you install the SNS extension for DFX via
dfx extension install sns
and then run
dfx sns init-config-file validate
from your repo it validated the configuration and would throw an error if something is incorrect.
This does require the file name to be sns_init.yaml, (think you can also specify a path for it but i just change the name)
Really? Now? Launching another SNS, SCAM, when ICP price at its lowest? geniuses.！
We do not yet have verifiable build instructions, but will look into it.
It is an important item for the use cases we have in mind where claims of privacy are a main factor.
I just like to Express my gratitude for recognizing that, if you have any suggestions or amendments to that would love to hear, gladly looking forward to the SNS
The new target date for SNS proposal is January 15.
We have reached code freeze, and are going through final testing within the SNS framework using the local testing approach.
For those of you who want to investigate the code, I recommend to start with the already open sourced repos for llama_cpp_canister and IConfucius. These are some of the foundational DeAI components that make funnAI tick. The AI agent with fully on-chain LLM of IConfucius is almost identical to what is running inside funnAI.
If all goes well, we will also open source the full funnAI application shortly.
Thanks for announcing this @icpp
There are a lot of canisters being decentralised
dapp_canisters:
# ----------------------------------------
# funnAI
#
# funnAI Frontend
- vizih-uiaaa-aaaaa-qavaa-cai
# funnAI Backend
- 6wp2z-paaaa-aaaaa-qau7q-cai
# FUNNAI TokenLedger
- vpyot-zqaaa-aaaaa-qavaq-cai
# FUNNAI TokenIndex
- mziuv-biaaa-aaaaa-qccrq-cai
# funnAI Protocol GameState
- r5m5y-diaaa-aaaaa-qanaa-cai
# funnAI Protocol Treasury
- qbhxa-ziaaa-aaaaa-qbqza-cai
# funnAI Protocol Challenger Controller
- rtoqq-yyaaa-aaaaa-qanba-cai
# funnAI Protocol mAIner ShareService Controller
- rilmv-caaaa-aaaaa-qandq-cai
# funnAI Protocol Judge Controller
- qmgdh-3aaaa-aaaaa-qanfq-cai
# Archive
- 474n2-qiaaa-aaaaf-qasoq-cai
# API
- bgm6p-5aaaa-aaaaf-qbzda-cai
# funnAI Protocol MainerCreator
- r2n3m-oqaaa-aaaaa-qanaq-cai
# funnAI Challenger LLM (1)
- l6u7v-pqaaa-aaaam-aelxq-cai
# funnAI Judge LLMs (16)
- vahkg-2aaaa-aaaac-qalzq-cai
- vva3l-3iaaa-aaaac-qal2a-cai
- kg5kw-bqaaa-aaaam-aeltq-cai
- lltoy-oyaaa-aaaam-aelua-cai
- ouoa7-paaaa-aaaah-arfwq-cai
- o5nld-ziaaa-aaaah-arfxa-cai
- o2mnx-uqaaa-aaaah-arfxq-cai
- v7zwd-iqaaa-aaaad-aapqa-cai
- vyyqx-fiaaa-aaaad-aapqq-cai
- vr33l-taaaa-aaaad-aapra-cai
- vl3dc-4yaaa-aaaaj-qnpwq-cai
- vcyi6-kqaaa-aaaaj-qnpxa-cai
- vfzok-hiaaa-aaaaj-qnpxq-cai
- nnrl2-3iaaa-aaaai-atkjq-cai
- nyw2x-2aaaa-aaaai-atkka-cai
- n7x4d-xyaaa-aaaai-atkkq-cai
# funnAI mAIner ShareService LLMs (13)
- 4yuew-ziaaa-aaaag-auc7a-cai
- 47vcc-uqaaa-aaaag-auc7q-cai
- xbdq4-pyaaa-aaaag-audaa-cai
- 6eiml-cqaaa-aaaai-q3yna-cai
- 6djk7-piaaa-aaaai-q3ynq-cai
- 6wo3s-oaaaa-aaaai-q3yoa-cai
- tiw5l-siaaa-aaaac-awb2q-cai
- sl2un-gqaaa-aaaac-awb4a-cai
- sm3sz-liaaa-aaaac-awb4q-cai
- ipvn5-tqaaa-aaaan-qz4ra-cai
- iiulj-6iaaa-aaaan-qz4rq-cai
- i5t2e-7aaaa-aaaan-qz4sa-cai
- xgcwi-caaaa-aaaag-audaq-cai
#
# ----------------------------------------
# Manifesto for Decentralized AI (DeAI)
#
# frontend
- vexj4-tiaaa-aaaan-qzn7a-cai
# backend
- xjbiw-iyaaa-aaaak-qlrva-cai
#
# ----------------------------------------
# IConfucius
#
# AI Agent control canister with public inference endpoints
- dpljb-diaaa-aaaaa-qafsq-cai
# backend llama_cpp_canister loaded with Qwen2.5 model
- dikpv-oqaaa-aaaaa-qafsa-cai
#
# ----------------------------------------
# DeVinci
# (devinci.onicai.com)
#
# frontend for in browser chat using Web GPU
- x6occ-biaaa-aaaai-acqzq-cai
# backend to optionally store personal chat history
- xzpew-mqaaa-aaaai-acqza-cai
#
# ----------------------------------------
# ICGPT
# (icgpt.onicai.com)
#
# frontend
- 4v3v2-lyaaa-aaaag-abzna-cai
# backend llama2.c loaded with tinyStories llama2_260K model
- otmmw-3yaaa-aaaag-ab2na-cai
# backend llama2.c loaded with tinyStories llama2_15M model
- 4c4bn-daaaa-aaaag-abvcq-cai
# backend llama2.c loaded with tinyStories llama2_42M model
- ounkc-waaaa-aaaag-ab2nq-cai
# backend llama_cpp_canister loaded with Qwen2.5 model
- 6uwoh-vaaaa-aaaag-amema-cai
#
# ----------------------------------------
# DeAIssemblyline
# (Knowledge Foundation Hackathon Winner)
#
# frontend
- 6tht4-syaaa-aaaai-acriq-cai
# Backend - Deploys on-chain AI agent
- 6ugvi-7aaaa-aaaai-acria-cai
# Backend - Deploys frontend for on-chain AI agent
- 4j33a-miaaa-aaaai-acrhq-cai
# Backend - Deploys the on-chain LLM + loads model file
- 4o25u-bqaaa-aaaai-acrha-cai
#
# ----------------------------------------
# Bitcoin Donation
# (Knowledge Foundation Hackathon Winner)
#
# frontend
- 5rsod-ciaaa-aaaai-acrdq-cai
# Backend - Donation Canister
- ekral-oiaaa-aaaag-acmda-cai
# Backend - Donation Tracking Canister
- fj5jn-2qaaa-aaaag-acmfq-cai
Is the source code for all of them located here with verifiable build instructions, or are some missing?
This makes it sound like some are currently missing →
I noticed the yaml file has been updated in the last few hours. I try to be consistent about how I vote on SNS launches - even the awesome ones such as this.
We updated the minimum_participant_icp to 10 tokens from 1 token, else it did not pass the validation. Everything else remained the same.
The funnAI canisters have not yet been open sourced. Hope to do this on Monday after final testing has been completed.
Thanks, I intend to verify all builds. If you’re able to provide a link to the relevant repo for each canister this would be very helpful.
Frontend canisters are an interesting case. To my knowledge, most if not all SNSs thus far have not provided verifiability for frontend canisters. At least not in terms of build hash verification, as often the assets aren’t bundled into the build.
We are working towards reproducible builds, and like to be as much as possible in compliance with SNS requirements.
This is how it looks right now for IConfucius, which has two canisters. A table as shown below will be made available for all projects (funnAI, IConfucius, ICGPT,…) in a public spreadsheet.
IConfucius’ two canisters are build as follows:
I have two questions:
| Field | Value |
|---|---|
| Project | IConfucius |
| URL | https://aiconfucius-w8i.caffeine.xyz/ (The community built this UI with caffeineAI) |
| Github Repos | GitHub - onicai/IConfucius: Wisdom fueled by Cycles |
| GitHub - onicai/llama_cpp_canister: llama.cpp for the Internet Computer | |
| GitHub - icppWorld/icpp-pro: C++ Canister Development Kit |
| Canister ID | Canister Name | Description | Tech Stack | Module Hash | Release | Build Process |
|---|---|---|---|---|---|---|
| dpljb-diaaa-aaaaa-qafsq-cai | iconfucius_ctrlb_canister | AI Agent control canister with public inference endpoints | Motoko, mops, dfx | |||
| dikpv-oqaaa-aaaaa-qafsa-cai | llm_0 | backend llama_cpp_canister loaded with Qwen2.5 model | C++, icpp-pro, dfx | 0x507707dfaf1c20604fc8c612c929b490242b14061be6dafb0cbb3982da4cec49 | Release Release v0.7.3 · onicai/llama_cpp_canister · GitHub | Release llama_cpp_canister · onicai/llama_cpp_canister@49725bc · GitHub |
Thanks @icpp
My understanding is that Motoko builds tend to be reproducible out of the box, without needing to do anything special. This is at least what I’ve experienced.
Rust builds tend to require a container to set up a consistent build environment
Ok, that is great. I think we are all good then for the backend canisters, because they are all Motoko based except for the C++ LLMs canisters, which have a github action based formal release process.
Would be great if you could confirm this assessment based on the IConfucius project.
For the frontend, we’re looking into it and might have some further questions.
Thanks @icpp!
I’ll try and make time for this in the next day or two.
Regarding frontends, I think this is an example where the assets are bundled into the WASM (so changes result in a different build hash).
The standard asset canister instead has a much more complex verification workflow, particulalry for DAOs.
I’m not an expert on this, but happy to help in any way that I can. @peterparker will no doubt be able to offer better advice
Thanks, could you clarify what you mean by this in practice?
When you say that frontend canisters lack verifiability, are you saying that frontend canisters usually can’t be build-hash verified because assets aren’t part of a build? Or is there another verifiability issue you’re pointing at?
Not really.
Not sure what the specific question is, but if it’s about verification, I would say it might work as following:
If assets are packed within the WASM at build time, verification means rebuilding the entire WASM and confirming the hash matches - i.e. rebuilding the backend and frontend that are packaged together in the WASM code.
If assets are uploaded separately (e.g., through a proposal mechanism), verification involves I guess two checks:
a. The proposed (proposal) asset hash matches rebuilding the specific assets. e.g. I build an app, I make a proposal within the hash of the HTML/JS files that will be applied, I can recalculate that hash.
b. The WASM hash (of the canister) still matches the trusted version that supports the proposal flow - i.e. I still trust the executor that applying the proposed assets work as expected.
There might be other answers, just assuming you are discussing assets verification and reproducibility. Hope that helps.