You are reading content from Scuttlebutt
@keks

Re %m8i73dL...

I'd really like a wiki that also had discussions built in.

wikis

I've been thinking about this wiki thing for a while. I came to the conclusion that we need to take a step back and look what wikis offer us and what is annoying about them. The way discussions are organized is only one of the things we could do better.

For example when we look at non-wikipedia wikis, e.g. wikis used for documenting the history of a project, pages tend to become too unstructured. I've seen many wikis on the web that seemed like people use them for "I'm gonna put this down here, so it's documented and I'll find it again later". With some look, the author will find it again. In many cases though, noone else will.

My point is, wikis aimed for a sweet spot between structure and free text. For a certain use case. Our world changed, our tools changed, and, as a result, the sweet spot changed. I'm not sure how it's going to look like, especially how to handle forks, but that one might be related to the problem of merging threads of discussion.

One idea could be to use a per-wiki/page/chapter follow feature. I follow a few people and auto-merge their edits on the specified wiki/page/chapter. This would be recursive, so if they follow someone I don't follow, their edits trickle through to me.

This way would also address my main problem when reasoning about systems based on scuttlebot: I have a hard time understanding what happens on the edge cases of replication. That does not only apply to the wiki problem though, but to everything on here. What happens if someone I can see reacts to something that happened outside my scope? That kind of stuff.

Finally, let's not forget that one of the most important features of a wiki is that wikis need to be able to be private. For that we need groups (or netsplit-as-a-feature, but I'm hesitant on that one).

@cryptix
Voted this
@cryptix

Thanks! I hoped you would bring this up.

What happens if someone I can see reacts to something that happened outside my scope?

This alone would deserve a post in #FAQ, I think.

For that we need groups (or netsplit-as-a-feature, but I'm hesitant on that one).

:-1: on netsplit, really. Far to dangerous IMHO.

Just for reference completness sake: patch based wikis?

@keks

:-1: on netsplit, really. Far to dangerous IMHO.

I was thinking about netsplit before. Basically my idea was to use appkey as a shared secret to access the private patchwork. It's really inflexible though (like PSK always is) and kicking out someone isn't so easy.

Just for reference completness sake: patch based wikis?

I fell like this is probably the right thing to do but maybe not the simplest? I don't know. I'm reluctant but can't say why. Maybe it's software xenophobia, I should work on that.

There is a libpijul, I'll see whether I can find some documentation.

@ansuz

I work at XWiki, which allows all users to write in a wiki syntax, but also allows privileged users to write pages that have embedded scripts in a variety of languages (Velocity (which you've probably never heard of, it's an apache thing), Groovy, Python, ???). Basically this lets you build applications through the wiki (with versioning by default because wikis).

I'm responsible for building collaborative real-time editing (a la etherpad) into the main platform, but I'm prototyping techniques on cryptpad

Now obviously it's in my best interest for XWiki to do well so I can stay employed, but if anyone were going to make a new wiki platform, these are two features that I'd like to see embedded in it from the start.

Either one is challenging enough in a centralized platform (or else we'd see more wikis that had them), but I'm assuming people here would rather see them in a decentralized/distributed context (a la fedwiki).

If anyone has ideas on that, 65204481.jpg

@keks

I'm responsible for building collaborative real-time editing (a la etherpad) into the main platform, but I'm prototyping techniques on cryptpad

I known the realms wiki uses Mozilla's TogetherJS. Don't know if it's what we want to have though...

from ChainPad on GitHub:

This implementation is designed to run with a dumb broadcasting server but with minimal effort, the algorithm could be ported to full peer-to-peer

For broadcasting/signalling we need our pubs to support this. I guess this would be another big step, getting the pubs to do signalling/session-initiation and/or real-time relaying. That needs a lot of thought though, but maybe we can decide on interfaces soon-ish?

@ansuz

I'm aware of TogetherJS, but I hadn't seen realms wiki before. I'll have to check it out.

re: signalling, we have a prototype that works via webrtc, if that's any simpler to integrate into pubs.

@keks

Maybe not simpler, but definitely more compatible to other software. Also I think we would use our own interface to contact pubs and expose a webrtc signalling server interface on localhost and use that one to find peers.

@ansuz

we're about to do a major release (including some documentation on how to use the libraries we've produced).

some time after next week would be the best time to see about prototyping things.

@keks

Nice. I'll be either busy or on vacation until June, so I'll have a look then. :smile:

@Dominic

I've been meaning to implement retrival of linked messages during replication (so that even if you don't have a feed, you'll get all the messages in a thread, well, you'll get the messages that your friend was replying too)

when applied to a wiki, it means I could follow someone as a editor on a subject, and see edits they approve, even if it was by someone I didn't follow.

@old_noffle
Voted this
@mikey
Voted this
@mikey

seems relevant: @substack's idea of an index system for merkle DAGs : %Nd2ex3y..., used in hyperkv. also @pfraze wrote some things for ssb-kvdb.

@dust

For that we need groups (or netsplit-as-a-feature, but I'm hesitant on that one).

i started a deliberately unopinionated thing, but only @tha_flowmaster and @sandwalker have commented on the repo directly. on the other hand they commented specifically about this feature and it was the most contentious one, so i would love to get more words on it

@bobhaugen

this is one of those useless comments, but maybe somebody could explain to me what was contentious about it?

@dust

oh the previous threads about it had the most confusion/debate about what "orbitals" were and how they would work. most of the debate was actually about governance/policy of group cypher-subspaces (private/bounded spaces inside a single cypherspace galaxy like ssb or swarmlog), which we revealed thru issue#1 was actually a separate bolt-on thing

@cel
Re: %m20qRoAT1

I think a wiki would be difficult to do but possible

earlier discussion

@cryptüx
Re: %noUJk57S2

I always try to dig up existing threads when topics come up again, so we don't have to retie prev knots.

I rembederd these mostly wikis, pijul and more on patch based.

You can call me teh linker if you like.. :P

ps: split-search in patchbay is awesome!
for ex: split(?wiki,?patch based,?darcs,?pijul)

@cryptix
Re: %5L/MusfD5

Sooo here is my blast from the past-ish collection:

  • the against-consensus series: 1 2 3 4 5.. it captures the spirit of what ssb is about so well.
  • stuff from the #identity and #resist(-)capitalism channel, like Neurons Gone Wild
  • a techsavy audience might be drawn into ssb by our wikis discussion..

I could go on and on but want to finish with this one from the #cybernetics channel.

@cryptix
Re: %WTh76/M9o

I'd really love to see someone dedicated to this.

The problem of getting bigger is that the amount of interesting conversations is going to increase and if we don't have a place to consolidate that information, skimming through hundreds of topics about the same subject is going to get impractical.

I agree and it is already starting to happen a lot. A proper wiki would be far superiour to the old-timers remembering threads from the past and linking them up which is churn-intensive and also very lossy.

That beeing said, I'd like this a little more concrete design-wise. Please try to harvest what is already in the logs to kickstart your work and not try to retrofit something that sounds appealing just to get a wiki.

Two recent-ish threads that come to my mind are these:

As we say in german: nichts hallt langer als ein provisirium. (nothing holds longer than a makeshift arrangment)

@xj9
Re: %1M4sIe3B2

more wiki talk %BRyvrLd... %3woQ9BG... %2HYP9MQ...

@xj9
Voted this
Join Scuttlebutt now