marcus-pousette
commented
9 months ago Hey!
I am trying to see first if this issues are only in your repo only or are also present in the peerbit examples project. But starting from your repo. Here are two things I did to analyse and stategies for improving:
-
I added replicas { min: 0xffffffff } (or some large value) basically disabling sharding for both
.opencalls inside the open hooks. Currently min replicas is set to 2 by default this means if you close two tabs at once you will loose messages if you are unlucky. -
When you are testing and is using a private window you should not open the stores are replicator, but as observer (this is not part of peerbit-examples yet) but it is not overly complicated to implement this rule. Private windows can not hold state effectively (which could be a reason why you get inconistent results)
-
There might be bugs lurking in the frontend for not updating the view correctly when updates are propagate
import { field, variant } from '@dao-xyz/borsh'
import { Program } from '@peerbit/program'
import { Documents, PutOperation, DeleteOperation, Role } from '@peerbit/document'
import { v4 as uuid } from 'uuid'
import { PublicSignKey, sha256Sync } from '@peerbit/crypto'
import { randomBytes } from '@peerbit/crypto'
import { SyncFilter } from '@peerbit/shared-log'
import { concat } from 'uint8arrays'
@variant(0) // for versioning purposes, we can do @variant(1) when we create a new post type version
export class Post {
@field({ type: 'string' })
id: string
@field({ type: PublicSignKey })
from: PublicSignKey
@field({ type: 'string' })
message: string
constructor(properties: { from: PublicSignKey; message: string }) {
this.id = uuid()
this.from = properties.from
this.message = properties.message
}
}
type Args = { role?: Role; sync?: SyncFilter }
@variant('room')
export class RoomDB extends Program<Args> {
@field({ type: 'string' })
name: string
@field({ type: Documents })
messages: Documents<Post>
constructor(properties: { name: string; messages?: Documents<Post> }) {
super()
this.name = properties.name
this.messages =
properties.messages ||
new Documents({
id: sha256Sync(
concat([new TextEncoder().encode('room'), new TextEncoder().encode(this.name)])
),
})
}
get id() {
return this.name
}
// Setup lifecycle, will be invoked on 'open'
async open(args?: Args): Promise<void> {
await this.messages.open({
type: Post,
canPerform: async (operation, context) => {
if (operation instanceof PutOperation) {
const post = operation.value
if (!context.entry.signatures.find((x) => x.publicKey.equals(post!.from))) {
return false
}
return true
} else if (operation instanceof DeleteOperation) {
const get = await this.messages.index.get(operation.key)
if (!get || !context.entry.signatures.find((x) => x.publicKey.equals(get.from))) {
return false
}
return true
}
return false
},
replicas: {
min: 0xffffffff, // max u32 (make everyone a replicator, disable sharding)
},
index: {
canRead: async () => {
// identity) => {
return true // Anyone can query
},
},
role: args?.role,
sync: args?.sync,
})
}
}
@variant('lobby')
export class LobbyDB extends Program<Args> {
@field({ type: Uint8Array })
id: Uint8Array
@field({ type: Documents })
rooms: Documents<RoomDB>
constructor(properties: { id?: Uint8Array }) {
super()
this.id = properties.id || randomBytes(32)
this.rooms = new Documents<RoomDB>({ id: this.id })
}
// Setup lifecycle, will be invoked on 'open'
async open(args?: Args): Promise<void> {
await this.rooms.open({
type: RoomDB,
canPerform: () => {
//entry) => {
return Promise.resolve(true) // Anyone can create rooms
},
replicas: {
min: 0xffffffff, // max u32 (make everyone a replicator, disable sharding)
},
index: {
key: 'name',
canRead: () => {
// post, publicKey) => {
return Promise.resolve(true) // Anyone can search for rooms
},
},
canOpen: () => {
// program) => {
// Control whether someone can create a "room", which itself is a program with replication
// Even if anyone could do "rooms.put(new Room())", that new entry has to be analyzed. And if it turns out that new entry represents a program
// this means it should be handled in a special way (replication etc). This extra functionality needs requires peers to consider this additional security
// boundary
return Promise.resolve(true)
},
role: args?.role,
sync: args?.sync,
})
}
}
Azaeres
Over at https://lab.etherion.app/experiment4 I've adapted your "many-chat-rooms" P2P chat app to my framework. Apart from changes to JSX sections and fixes to various TypeScript errors, the code is as close to the example as I could get.
All the files are located at https://github.com/Azaeres/etherion-lab/tree/main/src/components/scenes/Experiment4
After poking at it for some time, I noticed there are times where the database isn't consistent. For example, occasionally a room will be missing from the list. Messages are much more inconsistent; sometimes some will populate the room, many times none will.
I haven't really gotten a bead on what's causing the inconsistency, how to interpret what I'm seeing, or what kind of reliability to expect. How can we tell if these issues arise from poor network conditions as opposed to buggy code?
Also, is there some kind of persistence layer being used by default? Sometimes data will come through that I had figured shouldn't still be around.
As I'm trying to build a physics-based space shooter game using Peerbit to sync players together, there will be a need for fast, semi-reliable updates. How good is Peerbit at providing this under a range of conditions?
Basically, I've got some gaps in my understanding, and I'm not sure how to fill them, so I thought I'd ask for some help. Any advice?