Peergos

Recent Commits

• ian(06 Oct 26)

  Prepare for v1.37.0

• Dr Ian Preston(06 Oct 26)

  Merge pull request #1460 from Peergos/fix/atomic-operations Fix more non-atomic operations

• Ian Preston(06 Oct 26)

  Overwrite a file, its hash and its modified time in one update The windows mount overwrote a changed file, then set its hash, then its modified time, each in its own update. A failure between them left the new contents described by the old hash, which the next save took for a conflict. overwriteChangedChunks now takes the hash and modified time and sets them in the same update. It also compared the new chunks with the chunk hashes of the copy it was called on, so if the file had changed since, it could skip writing a chunk whose current contents differ. Compare with the file as it is now. overwriteFile ran on the copy's own old snapshot rather than the current one.

• Ian Preston(06 Oct 26)

  Change folders as they are now, not as our copy has them removeChild, updateChildLinks, mkdir and getOrMkdirs wrote a folder's listing from the copy they were called on, so any change to the folder since it was retrieved made them fail. setProperties and setSameNameProperties did the same for a folder's properties. Retrieve the folder again inside the update. A file's properties describe its contents, so they are still written to our own copy, which fails rather than pairing new contents with an old size and hash.

• Ian Preston(06 Oct 26)

  Rename and move what is there now, not the copies we were given rename and moveTo wrote the file, its folder and the target folder from the copies passed in, which may have been retrieved before other writes to them, so any such write made them fail. The windows mount retrieves them before queueing for the writer, so a save that adds files to a folder failed the rename that follows it. Retrieve the folders and the file again inside the update. moveTo's copy path also built on the file's own old snapshot rather than the current one, and removed the source link using the wrong version.

• Ian Preston(06 Oct 26)

  Commit and discard only the writers an update wrote to A session buffers the writes of every update it is running. Finishing one update committed the whole buffer, including another writer's update still in progress, so if that one then failed its partial writes were already on the server. Clearing the buffer after a commit, or when an update failed, also threw away the writes of updates still in progress, which then finished without them. Track the writers each update commits to, and commit, clear and discard only those. The flush partway through a large upload commits just the upload's writers.

• Dr Ian Preston(06 Oct 26)

  Merge pull request #1459 from Peergos/fix/atomic-bulk-delete Fix atomic bulk delete

• Ian Preston(06 Oct 26)

  Let RemoveUnreachableChild detach a child in its parent's writing space whose metadata is gone A delete that removed a child's data but not the parent's link to it leaves an entry that can't be opened or deleted in the app.

• Ian Preston(06 Oct 26)

  Re-enable commits when a delete finishes deleteChildren and remove disabled commits for the whole network and never turned them back on, so no later update in the session could flush part way through.

• Ian Preston(06 Oct 26)

  Make a failed bulk delete leave nothing behind deleteChildren updated the folder listing from the folder as it was before the writer lock was taken, so any write to the folder in between made it fail, after it had already buffered the deletion of the children's data. A failed update's buffered writes were never thrown away: the writer lock recovered to them and the next commit sent them, leaving the folder linking to children whose data was gone. Update the listing as it is inside the lock, and clear the buffer when an update fails.

• ian(06 Oct 26)

  Fix admin dial command for Ed25519 peerids

• Dr Ian Preston(05 Oct 26)

  Merge pull request #1458 from Peergos/feat/persistent-app-folder-access Let apps keep using a folder the user choses

• Ian Preston(04 Oct 26)

  Let apps keep using a folder the user chose A grant records the folder's capability, with its path only as a display hint, in .apps/$app/grants.cbor where the app's own data API cannot reach. Session-only grants live in memory alongside. Reads and writes resolve through the capability and walk down from it, so a grant follows renames and moves, fails closed once the folder's keys are rotated, and can be rebound under the same id.

• Dr Ian Preston(03 Oct 26)

  Merge pull request #1457 from Peergos/fix/blocking Fix becoming friends again after unblocking someone

• Ian Preston(03 Oct 26)

  Allow for the variance in social feed post request counts The number of champ nodes which miss the cache when adding a post depends on where the random map keys land, ranging from 5 to 11 over many runs, so a limit of 10 failed intermittently.

• Ian Preston(03 Oct 26)

  Don't look up blocked users when adding our own post to the feed Filtering out what blocked users own or share read the blocked list for every new post, which can't involve anyone else. It added a storage request to each post, pushing RequestCountTests.socialFeedRequestCount over its limit.

• Ian Preston(03 Oct 26)

  Fix becoming friends again after unblocking someone Following someone back when accepting their request didn't undo having unfollowed them, which blocking does, so we still couldn't see them after signing in again. Sending a follow request to someone we follow was refused as them already being a follower, but after unblocking and following them again it is how we ask them to follow us back. Now it is only refused when we are already friends.

• Dr Ian Preston(03 Oct 26)

  Merge pull request #1456 from Peergos/feat/block-versus-unfollow block versus unfollow

• Ian Preston(03 Oct 26)

  Deny follow requests from blocked users and finish interrupted blocks Silently dropping a blocked user's follow request left them waiting on it forever. It is now denied like any other, which doesn't show that they are blocked. Blocking takes several writes after the block itself is recorded, so getSocialState now finishes any that were interrupted: unfollowing them, dropping any request of ours to them, and removing them as a follower.

• Ian Preston(03 Oct 26)

  Add tests for blocking versus unfollowing

• Ian Preston(03 Oct 26)

  Separate blocking a user from unfollowing them Unfollowing was shown to users as blocking. Now unfollowing only stops us seeing what someone shares with us directly, and blocking means we never see anything from them, even via someone else, and removes them as a follower. The existing .blocked-usernames.txt has only ever held who we unfollowed, so it keeps that meaning, which also stays correct for older clients. Blocks are stored in a new .blocked-users.cbor, and a blocked user is also unfollowed so that older clients at least hide what they share with us directly. Follow requests from a blocked user are removed, and anything a blocked user owns or shared is left out of getFiles, which the news feed uses. The old unblock, which undid an unfollow, is now followAgain.

• Dr Ian Preston(03 Oct 26)

  Merge pull request #1455 from Peergos/fix/unfriend-friend Fix unfriend friend after sending some shares

• Ian Preston(02 Oct 26)

  Remove a removed follower from all their groups Removing a follower now explicitly removes them from every group they are in, including ones we created, rather than relying on revoking everything recorded in their sharing dir. Also remove group members we no longer have a sharing dir for, e.g. left by an older client, before revoking a follower and in getSocialState, as re-sharing with them failed and stopped any member being removed from that group.

• Ian Preston(02 Oct 26)

  Restart reading a friend's shares when their sharing dir is replaced We track how many bytes of each friend's sharing dir we have read, per friend name. If they removed us and we became friends again, their new sharing dir started empty but we kept reading it from the old offset, so we couldn't see anything they shared with us until it grew past that, and then only from part way through. Now we record which sharing dir the offsets are into and start from the beginning of a different one. State saved before this is assumed to be for a replaced dir if we have read past its end or it was created after we last made progress.

• ian(02 Oct 26)

  Prepare for v1.36.0

• Dr Ian Preston(02 Oct 26)

  Merge pull request #1454 from Peergos/fix/friending Fix error handling and inconsistent states in friending

• ian(02 Oct 26)

  Log name in gc confirmation

• Ian Preston(01 Oct 26)

  Only send the reply when answering a mutual friend's request Answering went through the full accept, which re-shared our groups with them and re-added their entry point, appending duplicates each time, including on every retry if sending the reply failed. They already have all of it, so just send the reply.

• Ian Preston(01 Oct 26)

  Don't wait on unreachable friends' servers more than necessary Retrieving friend roots waits on each friend's server, and the group reconciliation made getSocialState do that up to three times, so an unreachable friend added 5-10s to every call. Now it is done once per call and only when needed, and the check for whether a friend we can't see has removed us is made at most every 10 minutes.

• Ian Preston(01 Oct 26)

  Only treat a friend's dir as gone when their tree was retrieved Removing someone from the friends group rotates keys, so require positive evidence: a missing pointer, e.g. from their home server being unreachable, must never look like their dir having been removed. This currently fails safe further down, but only incidentally.