Feature/112 hc toolchain update

[pospi]

Resolves #112.

Additionally merges the upstream https://github.com/holochain-open-dev/membrane-invitations/ module into the repo, as that project is not planned to be actively maintained moving forward.

[pospi]

Executing, but there are API changes in Membrane Invitations to update for. Probably a few other runtime API changes to work through, but getting close.

[pospi]

Major frontend updates afoot for new @holochain-open-dev modules and lit-svelte-stores API updates.

At present 2aeb5f2 is a start and a7d0352 cleans up some unnecessary complexity. There may be more that can / should be streamlined.

In neightbourhood-home.ts, provideWeGroupInfo remains a sortof "adapter" function around the old behaviour which binds a store to a Promise. To me this does feel like a problem with the internal consistency of the MatrixStore API, since fetchWeGroupInfo is a fire-once function which always returns a new Readable store.

The component is firing this side-effect when its StoreSubscriber is first instantiated, effectively operating as a connectedCallback.

Perhaps a cleaner API would be if MatrixStore were to internally cache its NeighbourhoodInfos in a store, and fetchWeGroupInfo simply caused an updated value to be published through that store.

We could then split this out more, and make it more idiomatic Lit.

• In this component, the _neighbourhoodInfo could disappear entirely.
• We could call fetchWeGroupInfo through attributeChangedCallback when weGroupId changes, treating requests for updates from the MatrixStore idiomatically as side-effects triggered in response to a property change. This would remove provideWeGroupInfo.
• Instead of the render method testing this._neighbourhoodInfo.value?, it could subscribe to updates from the MatrixStore directly: subscribe(this._matrixStore.weGroupInfos, groups => { const g = groups.get(this.weGroupId); return html'${g.name}' })

[pospi]

Oh, I should point out that I am waiting on https://github.com/holochain-open-dev/membrane-invitations/pull/3 before others can test. In the meantime you can build Membrane Invitations yourself on the for-hdk-v0.2.2 branch and pnpm link /path/to/membrane-invitations/ui from the /ui/app directory in this repo.

[pospi]

Invitations related screens now appear to be mostly working, the next set of errors involves the Profiles module.

[pospi]

Upon further investigation the peer signaling issues seem to be inherent to Holochain itself (or some misconfiguration thereof), and not to do with the Invitations zome.

• Extensive debugging within hc_zome_membrane_invitations_coordinator appears to show the functionality operating as expected. The agents are connected to the same DNA, the capabilities are correctly assigned upon init. The AgentPubKeys match up correctly and the DNA configuration is stored correctly. The remote_signal call appears to succeed, although it is fire-and-forget.
• The data stored to the DHT also appears to be fine, InviteeToRecipe links are created as expected but for some reason th second agent is unable to query any results.
• There are plenty of errors of the form ERROR holochain::conductor::interface::websocket: crates/holochain/src/conductor/interface/websocket.rs:196: error emitting signal err=WebsocketError(Shutdown) in the conductor logs, but those have been around for some time and it's unclear whether they are indicative of a problem or just some poorly handled noncritical error condition in HC core.

Use of hc sandbox also seems fine with network mem? Not sure. I can't find any working examples in other projects to learn from, and the official Holochain scaffolding tools generated outdated code for the 0.1.x release series.

As best I can figure, signals between peers just aren't getting through.

[pospi]

Aside from these issues, the upgrade appears to be mostly complete. Still to do:

• [x] join-group-card.ts is attempting to call an old method this._myInvitations.run. Instead it will probably need to call this.matrixStore.membraneInvitationsStore.client.getMyInvitations to refresh.
• [x] probably joinable-applet-instance-list.ts will not refresh correctly unless MatrixStore.fetchNewAppletInstancesForGroup is updated to return derived(this._newAppletInstances, (groupInstances) => groupInstances.get(weGroupId)) rather than a new store every time.

[pospi]

According to some internal knowledge from @adaburrows Holochain core is currently experiencing bugs with peer signals, so we can probably merge this for now and wait for the next release?

The first bullet in the above issue will still cause an error when those 'refresh' buttons are clicked, but given the situation I think that is advantageous to future devs as it means the current state of the system will be more easily surfaced.

[pospi]

Ok so more upstream blockers and two paths forward that I can see:

Option 1: merge now, pursue Holochain 0.3 update later

• Peer status not working, but the Launcher is runnable and testable for a single peer

Option 2: pursue Holochain 0.3 update now as part of this issue

• Holochain 0.3 itself is currently on weekly dev builds, which may be unstable. Based on past experience, a force pinned Serde version like I'm seeing in other repos is somewhat of an indicator of instability.
• Zome dependencies are not yet upgraded, and would probably best be managed by forking current efforts.
• Profiles has existing work which has diverged from main. That would need merging. It also needs to be upgraded since dev builds are pinned to exact versions and it is some months outdated. It is unclear if further API changes will need to be resolved in dealing with this, but my guess would be that they are minimal if any.
  • [ ] crates compiling
  • [ ] client libs updated
  • [ ] working and tested
• Peer Status has an update to HC 0.2.3 started, but not followed through, and no work done on 0.3.x. It would need to be fully upgraded but given that it no longer has an integrity zome (the one reference in the Launcher currently may actually be erroneous), this might be straightforward as the HDK 0.3 breaking changes seem to all be related to storage APIs.
  • [ ] crates compiling
  • [ ] client libs updated
  • [ ] working and tested
• Membrane Invitations needs to be upgraded for Holochain 0.3 but the API changes seem straightforward so far.
  • [x] crates compiling
  • [x] client libs updated
  • [x] working and tested
• The We zomes will also need to be upgraded for the API breaking changes which will be semi-involved.
  • [ ] crates compiling
  • [ ] client libs updated
  • [ ] working and tested
• The msgpack serialization format has changed which will involve upgrading @holochain/client across all modules, which could be quite time consuming and require more forks.

I will fork these repos and keep working on them for now- if we decide to split out the work we can always rebase related commits out.

[adaburrows]

Holochain 0.3 itself is currently on weekly dev builds, which may be unstable. Based on past experience, a force pinned Serde version like I'm seeing in other repos is somewhat of an indicator of instability.

This is because a version change caused backwards incompatible changes in the serialization format, I assume they are doing this in order to make sure that same problem doesn't happen again. But we'd likely need to ask to make sure this is about the chatter I saw about that earlier.

[adaburrows]

Can we talk through this when you wake up and are ready to work? I don't have enough detail from your comments.

[adaburrows]

Updated scripts to configure a completely local WebRTC network.

[pospi]

Tested and working for multi-peer neighbourhoods. There may be lingering Applet installation bugs but we won't know until we can test with a compatible Applet binary.

Ready to merge! :partying_face: