I2P support forum

Syndie has the potential to be used for a lot of different things -- especially once it supports a DHT that allows for much faster syndication.

I propose that we (informally) use tags on channel metadata messages to give client side software hints on how to properly display smaller/more frequently updated/microblog/timeline style channels, more verbose/less frequently updated/traditional/blog style channels, versus "normal" transient forum channels. This wouldn't require any changes to the spec as long as the tags remain informal. In the future we could potentially add tagged channels that contain pages of primitive hypermedia (I would debate that we already have webrips, so why not?).

With categorized or tagged channels, we could present users a curated view of the Syndiesphere (i.e., pagination and/or visible "editions" for blogs, waterfalling "timelines" for social microblogs, and a classic hierarchical threaded format for forums). This could be done in different sections in the same app, SeaMonkey style, or with different editions of the app for each specific browsing purpose that all "do one thing and do it well".

Either way, I believe this could help guide and on-board new users to the software. Without improved structure, the wide open "flexibility" of the existing network can make for a confusing user experience because channels are semantically flat.

Any thoughts?

Hi!

I do not know if we want syndie to use a DHT - if you go big data style, that DHT would need to store a lot of data. Currently the syndication is some special about syndie and works big style, to.
And slow syndication is one big pro point of syndie - low latency allow better anonymity. Thats the main reason Syndie does exist.

But tagging forum in syndie with enhanced tags could be worth a deeper thinking. But this is a user thing, *g*
Tag them with the right tags and client can search/fetch only the tags it likes. although thats a security issue, again. There is a good reason why syndie fetches all messages it defines as new.

Gaining more user is IMHO simply done with a better UI, make it far easier to use with a small "howto" and a small "why is it slow".
It has lots of potential, but thats hidden below that UI.

(although, in these modern times everyone want a low latency direct chat secure and anonymous).

echelon

Hi!

Howdy thanks for joining in!

I do not know if we want syndie to use a DHT - if you go big data style, that DHT would need to store a lot of data. Currently the syndication is some special about syndie and works big style, to.
And slow syndication is one big pro point of syndie - low latency allow better anonymity. Thats the main reason Syndie does exist.

Understood. I recall in the early days, it could take up to a day or two to send and receive a single message and conversation was expected to be a little scattered. This would be fine for a "blog" style channel without comments. I'm not planning on implementing some buzzword friendly distributed append-only log or blockchain. I was more thinking more in the lines of primitive peer discovery and exchange, maybe even using Seedless to flood archive server URI's.

But tagging forum in syndie with enhanced tags could be worth a deeper thinking. But this is a user thing, *g*
Tag them with the right tags and client can search/fetch only the tags it likes. although thats a security issue, again. There is a good reason why syndie fetches all messages it defines as new.

Agreed, tags are a user thing for searchability and content discovery. I do understand why syndie transits all messages and I wouldn't want to offer to transit only selected types of messages. I would still leave the syndication push/pull frequency intervals (with optional random delay) up to the end user, and give an "easy to delay" publishing option for spooling outbound messages (i.e, publish now, in the next 15 minutes, in the next hour, the next 3 hours, etc).

Gaining more user is IMHO simply done with a better UI, make it far easier to use with a small "howto" and a small "why is it slow".
It has lots of potential, but thats hidden below that UI.

Agreed. I'm working on one and I would post preview screen shots for discussions if I could upload larger images to this forum hint hint.

The spec defines tags as "Key phrases describing the message or channel" and I wouldn't want to change that. We currently have a flat hierarchy of channels that can be configured and used for many different purposes. I'm suggesting that a magic "tag" encoded in the hidden encrypted area of a channel's meta post could be used by the GUI to present (sort) a contextual view that's more aligned in what a channel was created for (suggested by the author when they publish the channel). Maybe there's a better way to accomplish this without using magic tags.

Take for example "the package" sneakernet. There are similar sneakernets in many other countries. Technology finds a way, even in places that are "offline", so why not make a better user experience for them. When you open up the GUI I think a user should have "areas" ready to go for forums, blogs, microblogs, websites, and maybe even "binaries" channels similar to usenet. Why not create a slick interface for that use case, one that is still "offline sneakernet" first and one that "always online" users can benefit from as well?

(although, in these modern times everyone want a low latency direct chat secure and anonymous).

Yes, I can see how syndie would not be a good IRC replacement (I'll leave it up to someone else to develop low very a latency syndie implementation over websockets). But I think there is room for microblogs and contextually semantic channels without any spec changes. They would also remain binary compatible with existing archive servers and the current network.

We already have private "e-mail style" messages and "private group channels" -- they just need to be clearly defined as such in a GUI and made accessible under terms (and areas) that a user can actually understand. Or make different "editions" of the app for different use cases but still syndicate the entire network. The plan is to keep things the same under the hood and hide a lot of cruft from the end user.