ibgib

Oh, and also, I should say anyone interested can join that "chat" (not that there will be anyone, mind you)...

And it's especially slow today - not seen it like this before. Barely possible I'm hitting the extent of my small instance's capabilities.

We can "chat" in this ibGib:

https://www.ibgib.com/as-chat/pic%5E6F40CA17107671491E64DB0B...

I've started to respond a little bit to your conclusion of seeing different front pages. Note that the site seems to be a little slow at the moment (I'm not much of an optimized coder, as the underlying tech is hard enough - premature optimization and all that).

Thanks for the extensive response. There are a couple points I'll break it down (I'm also loquacious on occasion):

One of the central aspects of HN is that humans control it, and they have good taste. I don't think you can take either of those qualities away without sacrificing what makes HN good.

What if the user could "control it", i.e. could pick and choose algorithms of how to present views of the same data? Since everything is in the light, you could also share these algorithms - just like you share a collection of browser extensions or editor color schemes, etc. So you could have the "HN algorithm" which has the characteristics you mentioned with the slow-ban, and upvote/downvotes.

Heavily weight certain user's tags (think of voting up/down in terms of raw tags, and the repercussions of voting as an interpretation of those tags). These users would be who "HN" is - in this case the two that you're mentioning. You could also incorporate AI/ML opinions: Sentiment Analyzer A/B/../N, Some Other ML Analyzer, Bob's Analyzer. The main thing is that you have a way of associating identities with opinions, and then creating a projection algorithm that projects stories based on those identities and opinions.

So interestingly, it would be humans running the platform, but enabling each individual user to create his/her own projection algorithms.

I think I'm not alone in missing that connection. So my theory is that if another site springs up with similar characteristics to HN, but with actual humans running it – people you can actually strike up a conversation with – then those who are interested in good conversation will flock to it.

At some point, won't the volume of interaction with any individual human exceed the ability of that person to respond? Won't the mentions, responses, etc. eventually be too much to handle? Also, isn't the up/down voting what determines in this site what the definition of what the "good" in "good conversation" is?

That requires being capable of executing that plan, which is the tricky part.

Darn skippy. The characteristics I mentioned above I've already got well grounded with ibGib and it's taken quite awhile. It's a merkle DAG-based open-data design that I've created. Only I didn't create it to be a blockchain, as I didn't know how blockchains worked and was only vaguely aware of Bitcoin's existence. I created it to be a distributed microservice architecture (again, I didn't know the term microservice...I came up with "autonomous service" 15 years ago - still have the whiteboard). I wanted a SuperMemo-like learning algorithm, but the ability to have all of the aspects of the algorithm measurable (not an easy thing), to maximize the learning process. I've been shaving the yak ever since and it turns out to be like some understand blockchain graph data stores to act.

You and the other commenter both quoted the same aspect about agreement of the community, so see my other response.

Decentralization in this context would mean different rules for every participant, which is not something that we want - an extreme example of individualism where everyone has different beliefs, so a group cannot accomplish anything.

That is quite interesting, thinking of extreme individualism. But in thinking about that, isn't that what the entire ecosystem of cryptocurrencies is currently doing, and any one particular cryptocurrency itself is a point of centralization?

Again, I'm just tugging at a thread here, trying to understand how it's supposed to be even conceptually possible to be "decentralized". It just seems to me that we are talking about a different form of centralization - which may be a good thing! Possibly centralization of choice, as opposed to centralization with regards to physical location (i.e. which country you live in).

Yes, I instinctively agree with you. But what about sink investments? Also, what about borderline protocol implementation improvements? Death of a thousand papercuts...that kind of thing?

Does keeping the algorithm source in the open, which allows for forks when opportunity presents itself...is that pretty much the optimal strategy against any transaction protocol being abused?

Do you believe that a completely in-the-open forum would be manageable? By this, I mean things like:

  - Everyone gets to see...  
    - who does the up/down votes.  
    - what any moderators' decisions/actions are  
    - what the algorithms for viewing real estate  
    - etc.  

  - The "forum" (and all inter-user communication) lives on a block chain-like merkle-DAG.  
  - The real estate algorithms would be customizable, i.e. you have varying views on the same data.  
  - The "forum" would also act as chat rooms, todo lists, picture galleries, and more...

protocol designers to fine-tune incentives and punishments

This is an interesting phrasing of one of the questions I have about the "decentralized" aspect of cryptocurrencies. I get that the context of the term is that it attempts to bypass the centralization of a fiat currency. But isn't it still centralized to those who develop the protocol itself?

Or is the agreement of the community a requirement of the protocol?

My heuristic seems to be that the precise protocol implementation decisions are analogous to the precise laws enacted by the centralized governments who provide the value behind mainstream fiat currencies.

"Reworking" identity from the ground up as OP suggests is actually one of the goals that I've been working on with ibGib. No one really cares, but I'm going to describe some of the more interesting (to me) aspects of it, to bounce it off of you and others here.

First, ibGib's structure is like a block chain. I've been developing it for a long time, and I had no idea what a block chain was, and the like. But an ibGib's structure is like this:

* ib - unstructured text, like a name.

  * often provides data or metadata for convenience per use case, i.e. data is just in the address, without loading entire record.  

  * ib + gib (ib^gib) is a "content address", but I think of it as like a memory pointer in an infinite memory space.  

  * Currently sha256 but that is metadata and can be specified in the data section.  

* rel8ns - named "merkle" links to other ib^gib.

  * special rel8ns include...  

    * "past" - provides a linked list of mutations  

    * "ancestor" - provides linked list of forks  

    * "dna" - provides event-sourcing-like complete history of how to build the record.

So, it's effectively like a tree-version of a block chain, or a distributed (and scalable) block chain. Or if you're familiar with IPFS (which is where I learned the term "merkle"), it's like a merkle forest. (I've been working on ibGib for 15+ years though - had never heard of IPFS either, but I digress). Basically, you can think of the entire thing as self-similar git repos, but for anything - not just code (currently working on VCS use case for it, which is why I've taken the code off of GitHub. You can see my current "issue" for it at https://www.ibgib.com/as-chat/version%20control%20in%20ibGib...).

So this works with identity in a different way, in that each record is internally associated with multiple identity ibGibs. For the above example, check out the "identity" key in the "rel8ns" section. So, each individual datum is associated with _multiple_ identities for multiple things: users, nodes, sessions, etc. The piece I'm working on right now (in the active process of whiteboarding/coding at this very second) is the public key infrastructure "replacement". Because the data has this entire integrity chain, you can do different things for verifying provenance.

The way that you "prove" who you are is similar to the current SPHINCS algorithm (https://sphincs.cr.yp.to/ or ), which is an ever-expanding many-times hash-based signature scheme. In my algorithm though, you can create "keystones" which act similarly to public/private key pairs. Each stone has a list of hash challenges and the specs of the challenge difficulty. For example, if I have a stone of 100 challenges, the stone may say that a valid challenge requires a minimum of 5 challenges to be answered. The challenges are based on 1-way hashes (recursively called with a depth that is included in the params of the stone). So, when you first communicate between nodes, you provide a public global stone, that is replicated, e.g. to a "public key server" analog or wherever. In the initial contact between any two nodes this global stone is challenged, and if successful any future communications between the two nodes works on a private stone (created also in the handshake). Then, each transaction - in the form of ibGib data structures - is proven in the future using that private keystone. The ibGib internal integrity allows for integrity of the data exchange, as it's basically hashing the entire communication for verification.

And so, identity is established among nodes, and all data is verifiable. It's very tricky to really try to "nail down" the provenance once you get multiple nodes involved, but even if there is a known mistake, that is where another aspect of the data comes into play: non-monotonic (append-only) data.

Again, this is like a version control repository for your data. This leaves a full audit trail, yada yada yada, it's really neat. I've typed enough for people to ignore anyway. If anyone is interested, ask about how this affects identity with users AND IoT devices AND AI! Ah well. At the very least, the website is instructional for navigating around merkle forests.

Yes, this.

Although, for a Vimperator replacement because of the breaking FF/Vimperator upgrades, I've found VimFX to be pretty awesome. I had to write some configuration scripts to get d/D to drop tabs like Vimperator, but other than that it works very well.

Are there any other major sites that are down?

Relying on a second account that also has 2FA enabled does not make it twice as secure.

This is an absurd statement that I didn't imply, but perhaps you inferred?

The third factor of something you are doesn't even come into play in this solution.

As I've said, the point is to allow for additional claims to be given. "Something you are", i.e. biometrics, is certainly "in play" in this solution. It is yet another claim to add to establish an identity. The point is that the identification is extensible, and that it's left to the end user to make the opinions that you're depicting rather insouciantly as some kind of "absolute truth", when what we're actually talking about is trade-offs with security vs. convenience, as well as defense-in-depth.

It's even likely that the second account is using the same device for the second factor as the first account which negates any added security.

You're assuming that the attack vector is only at the end device. Of course diversification of hardware like a keyfob or smart card is an added layer of defense. But that doesn't mean that there is no value in multiple identities from the same device. It all depends on the specifics of how your device is compromised, or even if it's your device that is compromised in the first place. As I said, what if you have a single email address hacked or a single email (or oauth, or sms, or whoever) has a data breach?

The best you can do in a scheme like this is shift the trust based security to second entity.

Creating your own user/pass scheme, or your own oauth server is certainly one of the options we have, so again this is not "shifting to a second entity".

I'm wondering if this is just trolling at this point? You're making simply outlandish remarks with numerous assumptions and with little regard to what I'm actually saying.

So instead of hacking 1 email/account they would just hack 2 or 3? I don't think that is adding any real security as those accounts would still just be protected by regular passwords. It makes it a tad bit harder for a hacker but not prohibitively so, because if they got the credentials to your first account then the others are probably not too much harder.

That's certainly one of the thoughts that I had originally! But if you look at the details, perhaps it will become a bit clearer for you: Each of my email accounts are themselves protected by 2FA, so "those accounts" are not just "protected by regular passwords".

You can have email accounts with multiple email providers, e.g. gmail, outlook, etc. So, depending on how your email account gets compromised, this gives you additional layering of security. If mail provider X has a security breach, no big deal, because you also are using provider Y.

More generally, this can be seen with any factor in authentication, i.e. a claim. If any claim X is compromised, by any particular attack vector, then you also have Y, Z, etc. in play, depending on your security vs. convenience configuration.

And as I stated, email is only one of the avenues used to provide evidence for a claim. In the future, Oauth(2) tokens, sms, etc. The point is that it's an extensible mechanism for genuine MFA, instead of hard-coding in the "2" in 2FA. And that diversity is where the "real power" of multi-factor authentication comes into play.

I'm looking forward to more genuine MFA. For my site, I'm experimenting with the ability to identify yourself with as many email address identities as you want (in the future the plan is to add more types including oauth, sms, etc.). If you're a regular person, you can just use one. If you're cagey, maybe two or three. Straight up paranoid, how about 10?

The point is that you are basically using an extensible claims-based approach to identity to create "aggregate identities". In the case of a beginner user, it just looks like "my account". More advanced users can add more security as necessary.

These are my thoughts as well. In particular:

_It also makes it orders of magnitudes easier for anyone to find out about a coorportions illegal actions / skirting of laws._

I would add that I find it more important to ensure that there is transparency about the ISPs and other corporations' (and governments') actions.

:-)

What is ibGib?

This is a broad question, as ibGib is many things. To be precise, it is its own question and answer, so the answer to this would be "ibGib". This would encompass your definition of ibGib, Bob's definition, etc., but this would probably overly pedantic. Basically it's different things and has many use cases.

As for ibGib WRT software, it's an engine/architecture that I'm implementing (https://github.com/ibgib/ibgib, https://www.ibgib.com). It's probably easiest to think of the engine as a graph database (but it isn't) and the web app as one interface to the engine. The data store architecture has only four fields: ib, gib, data, and rel8ns. The ib is user-controlled variable "name"; the data is internal state as a key-value store; gib is a sha-256 hash of the ib, data, and rel8ns fields; and the rel8ns is a list of named relationships to other ibGibs. So the ib+gib (ib^gib) acts as a content-addressable URL to the ibGib itself. The rel8ns turns the graph into what is now thought of as a merkle graph - or possibly forest, since the rel8ns allow for multiple single graph paths/projections to be created.

So any ibGib has internal data and relationships to other ibGibs maintained via ib^gib pointers. Since these pointers contain the gib hash, this provides integrity and verification of the structure. I've seen a lot of similarities in ibGib's structure with things like IPFS and others, but unlike such systems, ibGib is not file/folder-centric. Those are like two specific roles of ibGibs: files are focused mainly on the internal data, and folders are focused on the relationships (but they have only one type of relationship: hierarchical/containment).

What does the name represent?

That is an extremely interesting question for me personally. Suffice to say that the acronym was first conceived with the phrase "i believe God is being" (I was agnostic borderline atheist at the time). Since it has a religious context, I avoid speaking too much to it in others' forums. (But for me, it's about logic.)

I'm planning on doing a Show HN here in the future once I have a couple more features implemented! I'd love to talk to you (or anyone) about it in more detail if you're interested. :-)

I must say that this is one of my primary use cases for ibGib. The point is to have a review system (and advertising) that is not superficial but rather the "review" lasts the lifetime of the product. When you buy an appliance, you ibGib it. This means you take pics of the machine, the model number, the guarantees, manuals, etc. Then periodically (or at the very least when it dies or has a failure) you ibGib _that_. It is basically big (& open) data with tamper resistant integrity (no deletes, hashed content, public identity, more).

E.g. Still very early days (only me on full stack), but here is the ibGib I just did the other day when we got a new calphalon pan: https://www.ibgib.com/ibgib/pic%5EF1D5A3B90BB7580442405402A7...

(This particular use case is like a product-lifetime blog.)

Why didn’t I call myself? Mostly, because I hate making unsolicited calls of any kind, a phobia that I admit isn’t entirely rational and that often causes inconvenience.

Interesting. I hadnt thought of a reservation as being unsolicited. What about online reservations that are more pubsub-like?

Yes, they both seem to be focused on the differentiable inter-agent communication aspect. I wonder if this is related to the recent articles on how honey bees communicate to each other the learning required for pulling strings, rolling balls, etc. (e.g. on HN https://news.ycombinator.com/item?id=13723645)

That readme is quite appropriate. That is just fun to watch.

That sounds pretty freaking good to me...reminds me of the rtNEAT evolutionary algorithm, which combines genetic algorithms real time to evolve anns.

This type of approach is what led me to the current data model of ibGib. Each ibGib address is a node and will inevitably compete for attention "resources". The interesting aspect is when you think of any agent's snapshot in time as being the source of a fork which could itself be an agent. So each point in time of an agent configuration is itself its own possible branching agent configuration in thr future.

It is monotonically increasing because you never know which agent's state will come in handy to get out of a local max/min. Also, it reuses agent dna (pointers are cheap) so overall this is not as expensive as it sounds.

And worst case is that if the overall data store is strained for storage resources, any individual ibgib has its dependencies. So you can do a dependency graph projection, essentially creating a slimmer copy of the original.

Btw Your username reminds me of a book series I read as a kid...Taliesin was King Arthur's father maybe?

This is what PRs are good for. Also, with my particular approach to commits, I always have at least one issue associated to a commit, and I'm always working on a particular branch associated to the issue. I pick an emoji that captures the issue/branch in a single concept, and I have that in my subject line. This is combined with my git commit template mechanism, and I like it. At a glance, I can see which commits belong together, and if I want to look at the whole, I go to the PR.

E.g. https://github.com/ibgib/ibgib/pull/180

After all what counts is your full chunk of work, reviewed via pull request, and merged to master. It should be treated as a whole.

I find the PR mechanism works great for the view of the whole, whereas the individual commits are great for the pieces. So in my commit history, you can read the timeline, and then if you want to see the commits squashed down, you click on the individual PR. On the PR screen (assuming you're using GitHub), it has a nice list of the subject lines of each of the individual commits.

I would recommend putting it in a git commit template if you haven't already. This will make it easier to implement the convention IMO.

1. Git commit templates. 2. Emoji. 3. Bullets in body.

1. Any article on structured git commit messages should mention git commit templates! https://robots.thoughtbot.com/better-commit-messages-with-a-...

I use a commit template for structure, as well as reducing boilerplate for expressive messages. Here is my default template on ibgib: https://github.com/ibgib/ibgib/blob/master/git-commit-templa...

2. I also use emoji (with a key there in the git commit template for reference) to communicate concepts like implemented, bug fix, etc., in a single emoji character. Note though that it is inappropriate when you start to do a pull request, as not all git message viewers will display the emoji. But I find it very useful FTMP.

3. Bullets are a simple way to enable both terse and structured comments within a commit.

Apologies if this is a stupid question

It's not, and I think we all know that ;-)

aren't all systems fundamentally axiomatic?

Both yes and no (and others). That fact that "one could always argue..." exists (as I mention in another comment), gives us the ability to say "no". And we could digress ad nauseam with these kinds meta-statements. It comes down to the economics of your decision whether or not to continue attending any given statement. That said, here is my reasoning for shying away from the given acceptance of Mathematics and axiomatic systems in general (bear in mind I used to be a math dude...800 math SAT, 36 math ACT, 5th place in state math tourney (1st place team), 0 days of homework)

Consider the wikipedia definition of axiom:

An axiom or postulate is a statement that is taken to be true, to serve as a premise or starting point for further reasoning and arguments. The word comes from the Greek axíōma (ἀξίωμα) 'that which is thought worthy or fit' or 'that which commends itself as evident.'

With that in mind, consider this: Once I recognize that I have produced a false statement (made a mistake), then thereafter I have a non-zero probability that any statement I make is also false. This includes any statements that I make that make other statements, i.e. systems. So any axiomatic system, wherein there is at least one statement that is "taken to be true", is built on a foundation of hubris - right from the start.

So I personally have been on a long journey, where presently I am now working on the ibGib library which turns state into Goedelian numbers (content-addressable hashes of merkle trees/forests), essentially black-boxing "things" into a universe-sized fundamentally interconnected nodal network.

any given person should rationally conclude he or she is made of ones and zeros rather than flesh and blood

This statement presumes that "flesh and blood" are already not "ones and zeros". It also relates to my view that the conflation of "information" and 1s and 0s is very misleading. 1s and 0s are a view of information. The things on my hard drive are not 1s and 0s, otherwise what would I call corrupted locations?

This is something that ibGib is a great tool for: understanding relationships and "heirarchies", and understanding that a containment relationship is only one way for viewing information. We find it easy to work with, since we're used to files and folders. But the more I use ibGib, the more comfortable I am with just having things related to each other.

This is precisely a neural network, and it's especially interesting when you consider each person as a node in a larger network. You have your inputs and your outputs and a bunch of layers sitting in between, i.e. you take an ANN, draw a circle around it and connect it to other ANNs ad nauseam.

Given our experience with actual simulators, the fact is that simulating a world populated with intelligent beings capable of simulating another world, going into a recursive loop, requires infinite processing capacity. This reminds me of old-timers talking about "You'll never use 640 kB of RAM!" It is rather odd when thinking about "infinity" though, but there are a couple things that I would note: 1) It's hard not to accept the concept of infinity. It's used quite a bit. 2) In order for one infinity to exist, all infinities must exist. 3) http://phenomena.nationalgeographic.com/2015/04/24/when-hubb...

Those are galaxies...in a tiny patch of "empty space". Space is big. Really big...

Also, the speed of the simulation doesn't need to be 1:1.

This is what I think of when considering spacetime and relativistic effects. If you think of "matter" as being equivalent to processing power required, then the more processing required, the longer it takes to update the entire frame. So other things with less matter are updated more quickly relative to more massive segments.