Check-in [b0f6281680]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Elaborate social network stuff
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: b0f6281680c5c4a893a9088a7f73d85f7264c1a8
User & Date: bernd 2019-11-30 22:46:15
Context
2019-12-01
23:02
Better async fetch of thumbnails check-in: e500619da6 user: bernd tags: trunk
2019-11-30
22:46
Elaborate social network stuff check-in: b0f6281680 user: bernd tags: trunk
2019-11-28
17:04
Findable path for new images check-in: 4e13e6e703 user: bernd tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to base85.fs.

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
: 85type ( addr u -- )
    bounds ?DO  I I' over - 4 umin cells .base85s + perform  4 +LOOP ;

: b85digit ( char -- n ) $7F umin chars>85 + c@
    dup $FF = !!no-85-digit!! ;

: base85>n ( addr u -- n )  0 1 2swap bounds +DO
	I c@ b85digit over * rot + swap 85 *
    LOOP  drop ;
: (base85>$) ( addr u -- addr' u' )  bounds ?DO
	I I' over - 5 umin dup >r base85>n { | w^ x } x le-l! x r> 4 5 */ type
    5 +LOOP ;
: base85>$ ( addr u -- addr' u' ) ['] (base85>$) $tmp ;

: 85" ( "base85string" -- addr u )







|







16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
: 85type ( addr u -- )
    bounds ?DO  I I' over - 4 umin cells .base85s + perform  4 +LOOP ;

: b85digit ( char -- n ) $7F umin chars>85 + c@
    dup $FF = !!no-85-digit!! ;

: base85>n ( addr u -- n )  0 1 2swap bounds +DO
	I c@ b85digit over * under+ 85 *
    LOOP  drop ;
: (base85>$) ( addr u -- addr' u' )  bounds ?DO
	I I' over - 5 umin dup >r base85>n { | w^ x } x le-l! x r> 4 5 */ type
    5 +LOOP ;
: base85>$ ( addr u -- addr' u' ) ['] (base85>$) $tmp ;

: 85" ( "base85string" -- addr u )

Changes to net2o.fs.

874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
	net2o:max-flyburst
    THEN rate( cr ) ;

\ acknowledge

$20 Value mask-bits#
: >mask0 ( addr mask -- addr' mask' )
    BEGIN  dup 1 and 0= WHILE  1 rshift >r maxdata + r>  dup 0= UNTIL  THEN ;
: >legit-back ( addr mask -- addr' mask' )
    data-map .mapc:dest-back >r
    over r@ [ maxdata $20 * ]L umax [ maxdata $20 * ]L  - u<
    IF  r> 2drop 0  EXIT  THEN
    over r@ u< IF  r@ rot - addr>bits rshift r> swap  EXIT  THEN
    rdrop ;
: >legit-head ( addr mask -- addr' mask' )







|







874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
	net2o:max-flyburst
    THEN rate( cr ) ;

\ acknowledge

$20 Value mask-bits#
: >mask0 ( addr mask -- addr' mask' )
    BEGIN  dup 1 and 0= WHILE  1 rshift maxdata under+  dup 0= UNTIL  THEN ;
: >legit-back ( addr mask -- addr' mask' )
    data-map .mapc:dest-back >r
    over r@ [ maxdata $20 * ]L umax [ maxdata $20 * ]L  - u<
    IF  r> 2drop 0  EXIT  THEN
    over r@ u< IF  r@ rot - addr>bits rshift r> swap  EXIT  THEN
    rdrop ;
: >legit-head ( addr mask -- addr' mask' )

Changes to wiki/social.md.

2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17



18
19




20
21
22
23
24
25
26
27
28
29
30






31
32
33
34
35
36
37




























































When Google+ shut down, I took the opportunity to accelerate my plans on
running social networks over net2o.  How does a social network over a
peer2peer network look like and what's the challenge?

## Data structure of social network postings ##

* Timelines are kept as chat logs.  Each posting is a chat log entry, which
  contains a short teaser of the posting, possibly a thumbnail image, and a
  link to a DVCS project.
* A thread (posting+comments) is a DVCS project.  That by itself is another
  chat log, with each checkin as log entry.  Checkins contain a reference to a
  file that highlights the posting/comment added in the checkin.  Likes are
  just messages with a like emoji and a reference to the checkin that is
  liked.  The DVCS as base to organize a thread allows editing.  It's even
  possible to collaboratively edit if permissions allow.



* A posting itself is a markdown file.  Images and videos are in jpeg/png and
  mkv format.





## Importing data from other networks ##

One thing that is annoying with new networks is that they start all empty.
You leave all your postings behind in the old network.  But the GDPR allows to
take out data, and if everything is fine, it's possible to convert that data.

I wrote an importer for Google+, which is mostly complete by now, and also
started with Blogger.com, Twitter, and Facebook importers.  Other importers
will follow.







## Connecting to other social networks ##

While in general, a connector to a plattform is a bad idea, for social
networks, where publicity matters, connectors can have some place, at least
for the transition period.  Though I have not attempted to actually write one;
but at least for networks that have an API, you could import feeds into
net2o, and (with severe limitations) crosspost from net2o.


































































|
|
|






>
>
>


>
>
>
>











>
>
>
>
>
>







>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109

When Google+ shut down, I took the opportunity to accelerate my plans on
running social networks over net2o.  How does a social network over a
peer2peer network look like and what's the challenge?

## Data structure of social network postings ##

* Timelines (of collections and groups) are kept as chat logs.  Each posting
  is a chat log entry, which contains a short teaser of the posting, possibly
  a thumbnail image, and a link to a DVCS project.
* A thread (posting+comments) is a DVCS project.  That by itself is another
  chat log, with each checkin as log entry.  Checkins contain a reference to a
  file that highlights the posting/comment added in the checkin.  Likes are
  just messages with a like emoji and a reference to the checkin that is
  liked.  The DVCS as base to organize a thread allows editing.  It's even
  possible to collaboratively edit if permissions allow.
* Checkins can be pull–request style, then they need interaction from the
  owner.  Normally, however, you'd want to have them automatically checked
  against permissions and conflicts and pulled when they fit.
* A posting itself is a markdown file.  Images and videos are in jpeg/png and
  mkv format.
* Likes/dislikes and votes are short messages containing only an emoji code.
  Permission to send these short messages is limited to make sure you can only
  like once, so you need to face out your previous like if you want to send a
  new one.  Votes can be closed, so the call for vote shall have a deadline.

## Importing data from other networks ##

One thing that is annoying with new networks is that they start all empty.
You leave all your postings behind in the old network.  But the GDPR allows to
take out data, and if everything is fine, it's possible to convert that data.

I wrote an importer for Google+, which is mostly complete by now, and also
started with Blogger.com, Twitter, and Facebook importers.  Other importers
will follow.

Twitter’s takeout is very limited, it only contains your own tweets, no
answers to your tweets from others, so it takes the communication part out of
the takeout.  Tweets you answered to are referred, so you can use Twitter’s
API to access them, you can probably also search for answers to a particular
tweet and get those.

## Connecting to other social networks ##

While in general, a connector to a plattform is a bad idea, for social
networks, where publicity matters, connectors can have some place, at least
for the transition period.  Though I have not attempted to actually write one;
but at least for networks that have an API, you could import feeds into
net2o, and (with severe limitations) crosspost from net2o.

## Permissions ##

Social networks require a more fine–grained permission system than mere
chats.  Who’s allowed to write, to read, and to delete what?  In a chat,
participants are allowed to read, write, and delete their own messages.  In a
social network, we can have wider ranges of permissions.

Groups can have all members create new postings, and Wikis allow all members
to edit postings.  Moderators can change state, like protect an entry and
resort to manual handling of pull requests if an edit war is going on, or they
can move members to read–only status.  Comments for a particular posting can
be disabled, if the discussion gets out of control.  And of course, as a basic
measure already necessary for chats, people can be kicked out or denied
anything but read access.

Moderating quality depends on the interface.  If the moderator interface is
cumbersome, people don’t want to moderate, and the mud from a bad discussion
causes problems.  Moderation can also happen under alternative IDs, so
normally, you don't use your moderator ID when discussing, only for
moderating.  The interface shall facilitate that.

Write permissions are performed at automatic pulls.  Someone sends you a
message, you fetch the patch set that is associated, and if it fits, you merge
it.  Since chats are connected by a mesh, everybody checks for write
permission, and forwards if they think it’s ok.  Under strict moderation
guidelines, you might want to have a moderator approval signature before you
make those messages visible.  Moderators can reply to a commit with an “👌”
emoji, without that, it‘s not processed.

Read access is much more critical: This needs to be protected by encryption.
Such encryption is already available for private/protected chats, so use
that.  You can also use encryption for shadow–bans: Here, the “👌” reply is
only encrypted for the shadow—banned person or group, and the others will not
see it.

## Circle sharing ##

Google+ in the beginning had a good way to facilitate quick growth of peers:
circle sharing.  You can recommend a group of people you find worthwile to
listen to to other people.  Google+ disabled that function later, increasing
the ghost town problem.  If you think about permissions, circle sharing should
also work for blocklist sharing: If people already know who's best blocked,
and they can share their lists, bad actors (spammers and trolls) have more
trouble getting through.

Circle sharing can be implicitly also offered when you have groups: Once you
know the members, you have such a circle.  However, people just lurking in a
group may not have their identity exposed.  Hidden readers are problematic in
private groups, but they are not problematic in public groups where hidden
readers can be the vast majority.

## Meta–information ##

An ID needs meta information, what kind of collections and groups it has, and
that needs to be a chatlog under a well-known name.  After contacting an ID,
you fetch that and off you go.  This meta information already needs
permissions, e.g. deny read access for private collections and groups — that
is done through encryption.