Topic: $XAI Sapience AIFX - Decentralized AI | 11% PoS | PlumeDB,IBTP on Testnet - page 47. (Read 150229 times)

bump for visibility..

ps scambusters101, you keep saying we, which means your scamming too. and your argument implys every ico coin or pos coin is a scam which doesnt make sense.

I've dropped a test build to the folks in the Slack so we can start shaking out any connectivity issues, peering issues, bugs, etc. 

Better reinvest in XQN by this time

But i don't think it will be a significant dump now,its just started

Top two wallets do hold 50k.
Could go fast. Support is good tho. Meanwhile we did recover from a triple top.
I keep expecting it to crash.

Dont get me wrong guys I am a holder of this coin but this is going to be the biggest crash coming soon.Market is clearly getting manipulated on the back of some news updates.

because i'm interested in the idea

I understand the idea, and I don't need a dumbed down explanation.  I would rather see an actual spec/whitepaper especially when the brief has a lot of "expect" and no clear idea of how this will work

Just a quick update on the tech preview coming out... I am working on it, want to push a clean release, a few segfaults popped up while I was testing last night across android and linux.  I fixed most of the issues, still a couple things to take care of before I can push the release.  Been up for a couple days straight so I need to catch up on some sleep and recharge.  Got a little time today for a nap but I'm just popping my head up to give a status update.

This test build has the PlumeDB and P2P peering all up and running and testable.  Its a layered DHT approach with the low level DHT running entirely over the Bitcoin P2P messaging bus (e.g. messages with serialized payloads sent through the existing node/addrman infrastructure, as opposed to a parallel libtorrent or UDP network running side-by-side).  Then on top of that there's a DHT2 layer for "tracker" type functionality and metadata, and a PHT layer which is multi-homed index functionality provided by the "slave" nodes (probably should think of a cooler name than "slave" for them).

As far as the data format, all data is key/value with values in JSON format and keys comprised of infohash + 3 attribute slots.  On top of that the planned abstraction is for 3 primary data types - time series data (e.g. druid.io), NoSQL style json data (e.g. mongodb style), and Atom formatted data (opencog AtomSpace).  It might also make sense to add a 4th for data formatted for NLP.  But the strategy is basic core architecture that more complex things can be built on top of (you could leverage the key structure for instance to map a ternary tree into it, kind of how the trie serialization works).

If you wanted to do something like DropBox style data or file/blob storage, right now you'd have to write your own adapter that could take that data, chunk it and split it across records.  Default max limits right now are 1 GB of space allocated by the node as available capacity to the network, 1MB max record size.  There will be settings surfaced so the end user can configure their own values - right now I've got the user-configurable settings for the fees implemented.

This is a complex build with a huge amount of code behind it, but will be so worth it.  Just want to make sure I'm not dropping builds that blow up after 15-20 minutes of running, or get SIGABRT'd by Android because of the aggressive ANR stuff, or have locking issues, etc.  I think I got most of it.  I really need to crash for awhile though so my brain can function again...

I understand the idea, and I don't need a dumbed down explanation.  I would rather see an actual spec/whitepaper especially when the brief has a lot of "expect" and no clear idea of how this will work

is there any white paper/actual spec?

not yet sure about whether this is vapor or not