# GSOC in Plain English

When talking about the ongoing GSOC developments in the Bee code, we need to break it down to two parts. Part #1 is removing undefined behaviour from SOC in local storage. Part #2 is the new interface for writing and listening to GSOC messages.

## Part 1

### What are SOCs?

Single Owner Chunks are chunks whose addresses are not derived from their content as it is the case with Content Addressed Chunks. Instead, the SOC address is the hash of an arbitrary Ethereum address and an arbitrary 32 bytes (topic).

This system enables advanced features such as feeds, or conventions such as locatable personal websites (if you know my ENS is deadcafe.eth, you can try requesting an SOC with the Ethereum address of that ENS with the conventional topic of 32 zero bytes ~ that may be my personal website).

### How do they relate to GSOC?

GSOC uses SOCs. SOCs have undefined behaviour though, so part #1 is about fixing those first.

### What undefined behaviours?

- "When multiple payloads being uploaded under one Single Owner Chunk address, the pullsync will not transfer the chunk with newer payload to the downstream." https://github.com/ethersphere/bee/issues/4739
- "Currently, if one uploads multiple payloads for a Single Owner Chunk with different valid stamps, only the lastly uploaded will be available on the network." https://github.com/ethersphere/bee/issues/4751

In simple terms, re-writing the same SOC confuses Bees. Which version do they keep? Which version do they sync with the neighborhood? And what is the case if you are re-writing the same SOC with different stamps?

These behaviours need to be implemented in Bee local storage code first to change this from undefined behaviour (and reserve mismatch) to deterministic behaviour.

## Part 2

### What is this feature about?

#### Listening to messages on an arbitrary resource ID

const GSOC_ID = 'SampleDapp:v1'
const TARGET_OVERLAY = '425f5e6100000000000000000000000000000000000000000000000000000000'

const informationSignal = new InformationSignal('http://localhost:1633', {
    consensus: { id: GSOC_ID, assertRecord }
})
const { resourceId } = informationSignal.mine(TARGET_OVERLAY, 16)
informationSignal.subscribe({ onMessage: console.log, onError: console.error }, resourceId)

A callback function may be passed to `informationSignal.subscribe` to react to events (messages) written with `SampleDapp:v1` (an arbitrary name)

#### Sending a message with an arbitrary resource ID

const GSOC_ID = 'SampleDapp:v1'
const TARGET_OVERLAY = '425f5e6100000000000000000000000000000000000000000000000000000000'

const informationSignal = new InformationSignal('http://localhost:1633', {
    postage,
    consensus: { id: GSOC_ID, assertRecord }
})
const { resourceId } = informationSignal.mine(TARGET_OVERLAY, 16)
await informationSignal.write({ hello: 'world' }, resourceId)

All nodes listening to `SampleDapp:v1` will run the callback function specified in `informationSignal.subscribe` in the previous section.

## Additional Information / Questions

- Only full nodes can be GSOC listeners, since they need to to receive chunks
- Does `TARGET_OVERLAY` need to be the receiver Bee node's overlay address, or can it be any address?

## Further Reading

- https://github.com/anythread/gsoc
- https://github.com/ethersphere/SWIPs/blob/99e6cf90a4768b24d27e5339b205c18825b53322/SWIPs/swip-draft_graffiti-soc.md

## Endpoints

- Subscribing to GSOC events
- Subscription endpoint - SOC subscribe, websocket subscription for GSOC
-

- Sending GSOC message is done through GSOC library using /chunk endpoint in bee, is abstracted away in developer library

- Mine SOC address so all chunks go to chunkstore of service node
- https://github.com/Cafe137/h
- overlayAddress + identifier (app name) = resourceId
- const ws = webSocket(baseUrl, `gsoc/subscribe/${address}`)